If you think AI-generated code fails because it’s buggy, Michael Ameling will politely ruin that narrative. As CPO of SAP Business Technology Platform, he says enterprises are “hitting a wall when generated code meets the reality of their existing environments,” and the issue is that generating code and operationalizing it are not the same problem.

That matters because, across industries, the mismatch between strategy and delivery is huge. SAP cites that 81% of all organizations have a detailed strategy, but only 12-16% reach AI-driven execution, and Ameling’s point is direct: the quality of the generated code is rarely the culprit. Instead, teams discover they cannot run what they built reliably inside their real, messy, integrated world.

So what does “messy” actually mean in enterprise life? It means compliance and security are non-negotiable. It also means the code has to run for the kind of timelines many big customers expect, “ten or twenty years,” and then be maintained, patched, and understood by whoever inherits it. In Ameling’s framing, lifecycle management is not something that magically generates itself, even if the initial output looks impressive in a demo.

The pattern usually starts with a tempting prototype. Teams build something compelling, then find the permissions are wrong, the integrations it assumes do not exist in the environment, or the data it depends on is missing or inaccessible. AI amplifies whatever data and process maturity an organization already has. It cannot substitute for missing readiness. And the problem intensifies as AI shifts from being a code generator to being an operational actor, where logic runs continuously against live systems instead of producing a one-time output.

Once you move from assistant mode to action mode, the engineering constraints change. Latency, cost, and system load matter more when workflows execute in real time against live data. An autonomous agent operating across a multinational’s transaction systems faces different performance requirements than a developer copilot that helps with snippets. The architecture has to support that difference, or you end up with something that performs well in a sandbox and breaks when it touches production.

That brings us to the integration challenge, which Ameling argues is what most enterprise AI projects underestimate. Real environments are rarely clean slates. They combine cloud and legacy on-premise infrastructure, fragmented data stores, and business applications that were never designed to talk to each other. Getting AI-generated logic to operate reliably across all of it requires a unifying layer that provides data access, process context, and governance, and that layer has to exist before agents start executing.

Importantly, Ameling also calls out a common misstep: treating AI as a reason to defer infrastructure modernization. His position is that you still need to modernize, and that the payoff for modernization is much higher when you add AI. “Federated data access and harmonized process layers are not alternatives to upgrading a fragmented landscape,” he says, “they’re what make the upgrade worthwhile.” In practical terms, the platform needs structured data integration, end-to-end process visibility, and the ability to discover and connect to APIs across both modern and legacy systems.

SAP ties this enterprise architecture approach to the Business AI Platform, citing components including Joule Studio, Integration Suite, Business Data Cloud, and the SAP AI Agent Hub. The goal, as described here, is not just raw data access, but accurate and current knowledge of what a business is doing and how. Agents then tackle big work by dividing it into smaller autonomous tasks. A financial close illustrates the concept: it involves dozens of discrete sub-processes, and parallel agent execution can compress cycle times, but only if the underlying systems are coherent and accessible.

Governance is the other half of the production equation. When AI goes from assistant to operational actor, agents trigger workflows, update records, and interact with live systems. That means they need accountability similar to human employees: identities, defined privileges, and auditable behavior. Two models show up in the source. Principal propagation lets an agent act on a user’s behalf, inheriting that user’s permissions and scope. System-triggered agents operate under their own identity and role-defined privileges, functioning more like an automated HR role than a personal assistant.

Both models rely on an agent hub where operators can see which agents exist, what APIs they can access, and what they are authorized to do. Observability also has to be operationalized for AI, combining technical and business evaluation. Ameling points to OpenTelemetry as the framework used to integrate with other solutions for end-to-end observability, including third-party agents. Technical evals test whether agents produce consistent outputs, but business evals ask a harder question: are agents actually moving the performance indicators they were deployed to improve, end-to-end?

Finally, the testing lifecycle changes. Traditional dev-test-production assumptions break down when a model produces different outputs depending on whether it is running against test data or live data. Getting trustworthy AI in production means validating differently than teams are used to, including live environment testing and even A/B/C testing to ensure outcomes are reliable. And yes, the developer’s role does not disappear. It shifts. Productivity can jump when developers run multiple coding agents in parallel across open terminals, each working for several minutes on a separate problem. But humans still have to stay in the loop: tracking context across concurrent workstreams, evaluating outputs across large codebases, and making architectural judgments agents cannot be trusted to make alone.

The most competitive advantage, in Ameling’s view, remains intellectual property, not tooling. The organizations that pull ahead are those that encode domain knowledge into the systems they build: a manufacturer’s process expertise, a financial institution’s risk logic, a logistics firm’s routing intelligence. AI can accelerate those assets, but only if the organizations that hold them do the work to make them accessible and usable. For boards and leadership teams, the strategic stakes are simple: if you build AI that cannot survive integration, governance, and lifecycle reality, you do not get execution. You get expensive prototypes that never scale.