Deterministic CI/CD is not enough for AI operations

CI/CD assumes the steps are known in advance

Continuous integration systems are excellent at what they were designed for: take a repository event, run a known sequence of steps, produce an artifact, report status. The sequence is declared ahead of time and the same inputs produce the same outputs.

Cross-system operational work does not have that shape. Investigating an alert means deciding which systems to look at based on what the first look revealed. That is a different control problem, and stretching a pipeline file to cover it produces something fragile.

Three things CI/CD does not model

First, caller-scoped authorization. CI/CD authorizes the repository and the environment, not the human or service that initiated the work and every downstream resource the run will touch. Second, approved AI access — which models, which tools, which scopes, resolved centrally rather than configured per job.

Third, operational context. A runbook, an architecture decision record and a policy document are inputs to a reasoning step. CI/CD has no concept of governed context because it never needed one.

What to keep

None of this argues for replacing CI/CD. Builds, tests and deployments belong exactly where they are, and the teams that own them have earned their conventions.

The productive pattern is composition: a Git event starts a governed run, the run performs the cross-system work that CI/CD was never designed for, and status flows back as a check run. Each system does the job it is good at.

A test for your own stack

Pick a workflow that already crosses three systems. Ask who authorized the last execution, which tools it was permitted to call, which runner executed it, and where the approval is recorded. If answering takes more than one link, the governance layer is missing rather than merely undocumented.