Adjacent practices

BROCS draws on disciplines that already operate production systems. This guide separates the practices that transfer directly from the changes required for AI systems.

The mappings to BROCS are interpretations, not endorsements by the cited organizations. See the evidence policy.

For the wider category, see enterprise AI operations. The MLOps and GenAIOps crosswalk covers the lifecycle disciplines used by teams that already operate machine learning or generative AI systems.

DevOps and DORA (Build)

DORA defines change lead time as the interval from a change committed to version control until it runs in production.¹ Apply that measure to code, prompts, tool instructions, retrieval configuration, and evals that follow a versioned delivery path.

The broader route from an approved idea to a running change is a value-stream measure. DORA distinguishes that end-to-end flow from its narrower software delivery metric.² Measure both. The broader measure exposes delays faced by analysts and other builders who do not work through a terminal.

Prompt and tool changes need version control, tests, release gates, and retained evidence of the version tested. The OWASP AI Agent Security Cheat Sheet documents these practices for agent releases.³

SRE (Run and Observe)

Error budgets, golden signals, postmortems, and end-to-end recovery tests transfer from SRE.⁴ AI services add token use, tool calls, model and prompt versions, unit cost, and measures of output quality. Provider quotas also become a saturation constraint.

Service health and output quality can diverge. NIST's guidance on deployed AI calls for monitoring real-world performance and unforeseen outputs after release.⁵ Evals belong next to service monitors so the team can detect behavioral regressions while latency and status codes remain stable.

OpenTelemetry's Generative AI semantic conventions cover model and agent spans, tool spans, events, metrics, and token attributes.⁶ The conventions remain in Development, so telemetry consumers should record the convention version they implement.

SecOps and AI security (Secure)

Least privilege and credential controls apply to AI systems. Agents need a complete review of the tools and data each identity can read, change, or send. OWASP classifies excessive functionality, permissions, and autonomy as excessive agency.⁷

Indirect prompt injection allows untrusted content to influence control flow. OWASP lists documents, source commits, tickets, web pages, and email as potential sources.⁸ The EchoLeak vulnerability shows this path through an email read by an assistant.

Platform engineering (Build and Run)

Internal platforms, self-service provisioning, reusable capabilities, and secure defaults transfer directly to Build and Run. The CNCF Platforms White Paper also describes access through GUIs, APIs, command-line tools, IDEs, and portals.⁹ This supports a shared identity, data access, and runtime layer beneath individual assistants and agent tools.

The sanctioned path has to work for routine use. Measure adoption and fulfillment time, then fix the path when teams work around it.

Secure software delivery (Build and Secure)

NIST's Secure Software Development Framework provides practices for preparing the organization, protecting software, producing secure releases, and responding to vulnerabilities.¹⁰ SLSA adds source and build provenance for software artifacts.¹¹

These practices transfer to code and packaged AI services. AI work extends the inventory to prompts, eval sets, tool definitions, model configuration, and retrieved data sources. Record the origin and approved version of each artifact used in a release.

GitOps and control loops (Observe and Control)

OpenGitOps defines desired state as declarative, versioned and immutable, pulled automatically, and continuously reconciled.¹² Those principles apply to model routes, prompt versions, tool permissions, and runtime policy when the underlying system can reconcile them.

A control loop needs measurements, a controller that selects a change, and an actuator that applies it.¹³ Observe supplies the measurements; Control supplies the adjustment. Teams need actions narrower than shutting down the whole service.

GRC, NIST AI RMF, and the EU AI Act (Secure)

NIST AI RMF 1.0 organizes risk management under Govern, Map, Measure, and Manage.¹⁴ BROCS maps Map and Measure to Observe, Manage to Control, and Govern to Secure. This is a BROCS crosswalk. The NIST Generative AI Profile adds risks and actions specific to generative AI.¹⁵ NIST is currently revising AI RMF 1.0.¹⁶

The EU AI Act assigns different duties according to the system classification and the organization's role. For applicable high-risk AI systems, Articles 12, 19, and 26 cover automatic logging, retention, and deployer control of logs.¹⁷ A BROCS review asks which production systems create those records and whether the responsible team can produce them on demand.

FinOps (Observe and Secure)

FinOps practices for allocation, budgeting, timely cost data, and unit economics transfer to inference spend.¹⁸ Attribute cost by application and team, then track a unit tied to business use, such as cost per resolved case.

Monthly reporting cannot constrain a retry loop while it is running. OWASP guidance for unbounded consumption recommends input limits, rate limits, user quotas, resource controls, timeouts, and throttling during operation.¹⁹