Infrastructure as Code for SAP BTP — the prerequisite for enterprise AI

The problem hiding in plain sight

Most enterprises running SAP BTP provision their landscape by hand. A subaccount is requested through a ticket. An engineer logs into the BTP cockpit, clicks through entitlements, assigns role collections, configures trust, and hands the environment off. Multiply that by a growing portfolio of extensions, sandboxes, and integration tenants and the cockpit becomes the bottleneck. Lead times of weeks per environment are common, and quietly accepted.

This is tolerable for traditional workloads. It is fatal for AI.

Why AI breaks click-ops

AI on SAP is not a single deployment. It is a sprawl of related resources that must all be consistent:

• SAP AI Core service instances and resource groups
• SAP HANA Cloud instances, often with vector engine capabilities
• Destinations pointing at S/4HANA OData or CAP services
• XSUAA scopes and role collections shaped to what an agent is allowed to do
• Identity federation via IAS/IPS with the corporate IdP
• Event Mesh topics for asynchronous tool calls and long-running agent workflows
• Logging, audit trails, and cost tagging

Get any one of those wrong and the behavior of the agent either drifts, leaks data, or silently fails closed. The thing nobody says out loud: the hardest part of AI on SAP is not the model. It is the landscape around it.

AI also changes the tempo of the platform. Pilots should fail fast. Promising experiments should scale across business units in days, not quarters. Failed experiments should be torn down cleanly, without a three-week cleanup project. Click-ops provisioning makes all of this harder, not easier.

What Infrastructure as Code actually changes

The core move is small and consequential: the cockpit becomes a UI, not the source of truth. The source of truth is a Git repository. Subaccounts, entitlements, subscriptions, role collections, destinations, trust configurations, AI Core resources — all generated from code.

Three practical choices matter more than the tool selection.

1. Pick boring tools deliberately

Terraform with the official SAP BTP provider covers the declarative majority of the landscape. The BTP CLI, wrapped in thin scripts, handles the edges Terraform does not yet cover cleanly — certain trust flows, AI Core resource groups, a handful of identity operations. That is the whole toolchain. No bespoke framework. Nothing a platform team cannot hire for.

2. Modularize by archetype, not by project

The trap is to write one module per project. The better shape is a small set of archetypes — “AI sandbox”, “CAP extension dev”, “integration hub”, “Fiori frontend”, “regulated workload” — each with opinionated defaults: quotas, mandatory role collections, mandatory destinations, logging, AI Core resource groups where relevant. A new environment becomes a short YAML file, not a sprawl of copy-pasted Terraform.

Archetypes force the hard conversation once — “what is a regulated workload, exactly?” — and then encode the answer. Every new environment inherits that answer. Drift becomes a pull request, not a quarterly surprise.

3. Embed governance in the pipeline

Policy-as-code runs on every pull request. No subaccount without an owner. No production-tier entitlement without a cost approver. No AI Core deployment without a data classification tag. No side-by-side extension without a clean-core declaration.

Audit stops being a quarterly panic. The Git log is the audit trail. Compliance stops being adversarial to the platform team, because the platform’s guarantees are mechanically verifiable.

The specific AI payoff

Once the landscape is code, AI changes shape:

• Deterministic sandboxes. Every AI pilot runs on an identical baseline — same quota, same logging, same identity federation, same guardrails. Behavior differences across environments stop being platform noise and start being real signal.
• Fail-fast by design. Retiring a failed pilot is a pull request, not a cleanup project. This matters because most AI pilots should fail fast, and the platform has to allow that economically.
• Fleet-wide reasoning. “Show me every subaccount with AI Core access and confirm it is tagged for data classification review” becomes a grep, not a survey.
• Safe fan-out. When a model, prompt, or vector-store pattern changes, it rolls to every relevant environment in hours, not quarters.
• Cost visibility. Tags propagate from code. AI spend is attributable by default, not reconstructed after the fact.

What IaC does not solve

It is worth being honest about the limits. IaC does not:

• Decide whether an AI use case is worth doing — that is still a product and domain call.
• Choose the right model, the right prompting strategy, or the right retrieval pattern.
• Replace data governance. If your master data is a mess, codifying the platform that serves it will not save you.
• Remove the need for humans in the provisioning loop — it shifts them from clicking to reviewing, which is a better use of senior time but still senior time.

IaC is the foundation. It is not the building.

A practical starting point

If your organization is still clicking in the cockpit, the useful first step is not “migrate everything to Terraform.” It is smaller: pick one archetype — the AI sandbox — and codify it end-to-end, with the full guardrails, as the canonical way to get an AI environment. Make the codified path faster than the ticket path. Business units will migrate themselves.

From there, expand archetype-by-archetype. Resist the urge to parameterize every flag. The value of archetypes is in the opinions they carry; strip those out and you are back to artisanal provisioning with extra YAML.

AI on SAP BTP scales when the platform team stops operating the cockpit and starts operating a pipeline. The tooling is mature enough. The excuse is gone.

Key takeaways

• The landscape is the bottleneck. Click-ops provisioning silently caps how fast AI can be adopted.
• IaC on BTP is production-ready. Terraform’s BTP provider plus the BTP CLI cover the realistic shape of enterprise landscapes.
• Archetypes are the design pattern. A handful of opinionated templates cover the majority of real demand.
• Governance belongs in the pipeline. Policy-as-code is durable. Slide-deck governance is not.
• IaC is the prerequisite, not the strategy. It removes the excuse. The AI strategy still has to be made by humans.