Business as Code: A Release Checklist for Enterprise AI Operations

Enterprise AI is leaving the demo room. The hard part now is not getting one chatbot to answer one team’s questions; it is turning policies, runbooks, prompts, approvals and agent behavior into a controlled operating system for the business.

That is the practical lesson inside Red Hat’s recent description of its internal “Business as Code” approach. Red Hat frames the shift as a move from isolated pilots toward operationalized AI, with business processes treated more like a codebase: versioned, reviewed, tested, promoted and rolled back when necessary.

This Learning Hub guide turns that idea into a release checklist for teams building enterprise AI workflows, especially agentic systems that can draft, route, summarize, recommend or trigger downstream actions.

Why “business as code” is more than a slogan

Red Hat’s argument is not simply that every department should use AI tools. The more important claim is that institutional knowledge becomes more valuable when it is structured enough for both humans and agents to inspect. In the Red Hat model, standard operating procedures, runbooks and policies can move into machine-readable formats such as Markdown and YAML, then inherit familiar software practices: version control, pull requests, code review, environment promotion, regression testing and rollback.

From AI pilot to operating model

A pilot usually depends on a small group of experts, a narrow dataset and manual supervision. An operating model needs repeatability. If an AI assistant is going to help with sales responses, finance workflows, legal review or HR operations, the organization must know which policy version the system used, who approved it, what tests passed, what actions the agent can take, and how to revert when a change causes unintended behavior.

That structure also maps well to broader AI risk guidance. The NIST AI Risk Management Framework is voluntary and use-case agnostic, but its core purpose is to help organizations designing, developing, deploying or using AI systems manage risks and promote trustworthy, responsible AI. Business-as-code practices make those risk decisions easier to audit because they leave a trail.

The enterprise AI release checklist

1. Put operational knowledge in a governed repository

Start with one high-value process rather than the whole company. Good first candidates are workflows with clear rules and repeated handoffs: discount approvals, RFP response intake, finance close checks, procurement exceptions, customer escalation summaries or legal playbook routing.

What to capture before automation

• The policy or runbook text in a readable format.
• The owner, reviewers and escalation path.
• The data sources the AI workflow is allowed to read.
• The actions the system may suggest, draft or execute.
• The cases where a human approval is mandatory.
• The tests that prove the rule still works after a change.

The goal is not to “document for documentation’s sake.” It is to convert fragile tribal knowledge into a managed asset that can be inspected, evaluated and improved.

2. Review policy changes before agents can use them

Red Hat explicitly compares business policy updates to pull requests and code review. That analogy matters because many AI failures are process failures before they are model failures. If a policy silently changes in a shared document, an agent may begin applying it before legal, finance, security or operations teams understand the impact.

Minimum review gates

• Business owner approval: confirms the process reflects the intended operating rule.
• Risk or compliance review: checks regulated, contractual or customer-impacting language.
• Security review: checks data access, prompt exposure, tool permissions and audit logging.
• Operations review: confirms the support team can observe, pause and roll back the workflow.

The review does not have to be heavyweight for every change. It does need to be explicit for any workflow that affects money, customer commitments, employee decisions, regulated data or external communications.

3. Separate development, staging and production business rules

Software teams do not normally push untested code straight into production. AI operations should not push untested policy changes straight into live agents either. Red Hat describes the same pattern for business operations: a policy can be piloted in one region or department before being promoted company-wide.

What staging should prove

• The agent selects the correct policy version.
• The output cites the correct source or rule.
• The workflow refuses actions outside its approved scope.
• The handoff to a human reviewer is visible and logged.
• Rollback returns the workflow to the last known good behavior.

For an RFP assistant, staging might mean generating drafts for internal review only. For a finance workflow, staging might mean comparing recommendations against historical cases without allowing the system to approve anything.

4. Turn policies into testable assertions

A business-as-code workflow should have tests. Some will be deterministic: “If a discount exceeds 30%, vice-president approval is required.” Others will be evaluation-based: “The agent must identify missing contract terms and route the draft to legal rather than inventing language.”

NIST’s AI Resource Center notes that the NIST AI 600-1 Generative AI Profile is a companion resource for AI RMF 1.0 and centers on 13 risks and more than 400 actions for managing them. That is a reminder that generative AI controls need more than a happy-path test. Teams should test for hallucinated policy, stale source material, missing approvals, unsafe tool use, privacy leakage and failure to disclose uncertainty.

A useful test set includes

• Normal cases that should pass automatically.
• Boundary cases that should require approval.
• Conflicting-policy cases that should escalate.
• Outdated-source cases that should be rejected.
• Adversarial prompts or documents that should not override the workflow.

5. Version prompts, retrieval sources and evaluations together

Red Hat describes an emerging agent development lifecycle with prompt versioning, continuous automated evaluations and safety guardrails. That is the right direction, but it only works if prompts are not treated as private strings hidden in a UI. A production AI workflow should record the prompt template, retrieval corpus version, policy version, model version, evaluation set and release notes together.

This also makes post-incident review possible. When an agent gives a bad recommendation, the team can ask a concrete question: did the model fail, did retrieval fetch the wrong source, did a policy change remove a guardrail, or did the workflow have too much authority?

6. Limit agent permissions before scaling

Agentic AI creates a different risk profile than a passive search assistant. The OWASP Gen AI Security Project’s guidance on Excessive Agency warns that damage often comes from excessive functionality, excessive permissions or excessive autonomy. Its mitigations include minimizing extensions, limiting permissions, executing actions in the user’s context and requiring human approval for high-impact actions.

Practical permission rules

• Prefer read-only access until the workflow has passed staging.
• Give tools narrow functions instead of open-ended shell, browser or database access.
• Use the requesting user’s identity where possible, not a generic high-privilege service account.
• Require confirmation before sending messages, deleting records, approving spend or changing customer-facing commitments.
• Log tool calls separately from model responses.

7. Keep rollback boring

The best rollback is the one operators can perform without a meeting. If a policy, prompt, retrieval index or model release causes bad behavior, the team should be able to return to the last known good version and preserve evidence for review. Red Hat’s business-as-code analogy is useful here: policies should have checkpoints, not just edits.

A 30-day pilot plan

Week 1: Choose one workflow

Pick a process with a clear owner and measurable outcomes. Avoid workflows that decide employment, credit, medical, safety or regulatory outcomes until the governance muscle is stronger.

Week 2: Convert the runbook into managed assets

Move the policy, examples, approval matrix and known exceptions into a repository or equivalent controlled system. Assign reviewers and define which parts the AI system may read.

Week 3: Build tests and a staging loop

Create a small evaluation set from real historical cases, redacted where needed. Include edge cases and misuse cases. Run the AI workflow in advisory mode only.

Week 4: Release with limits

Publish the workflow to one team or region with strict logging, limited permissions and human approval for consequential actions. Track false positives, false negatives, review burden, user trust and time saved.

When not to automate

Business as Code is not a reason to hand every process to an agent. Some workflows are too ambiguous, too sensitive or too poorly understood. If the organization cannot name the owner, source of truth, approval path, test cases and rollback process, it is not ready for production AI automation.

The near-term opportunity is narrower and more valuable: treat AI workflows like releasable enterprise systems. That means source-controlled knowledge, reviewed policy changes, staged releases, continuous evaluations, minimal permissions and rollback. The result is slower than a flashy demo, but it is much closer to an AI-enabled enterprise that can survive contact with production.

Sources

• Red Hat: The AI-enabled enterprise
• NIST: Artificial Intelligence Risk Management Framework (AI RMF 1.0)
• NIST AIRC: Technical reports, including the Generative AI Profile
• OWASP Gen AI Security Project: LLM06 Excessive Agency