EU AI Act readiness starts in the software delivery pipeline

At a glance

What this is: This article argues that EU AI Act readiness needs controls embedded into software delivery pipelines so teams can prove governance, oversight, and evidence at release time.

Why it matters: It matters to IAM and security practitioners because release workflows increasingly determine who approved AI-related changes, what evidence exists, and whether governance can be audited across human, non-human, and agent-driven delivery chains.

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirming one and 26% suspecting one.
• Only 44% of organisations are currently using a dedicated secrets management system.

👉 Read Arxan Technologies' analysis of EU AI Act readiness in the software delivery pipeline

Context

EU AI Act readiness is not just a policy problem, it is a control-evidence problem. If AI-related changes move through software delivery without enforced approvals, traceable oversight, and retained records, teams cannot demonstrate that governance actually happened. In practice, the weakest point is often the handoff between development, security, and release operations, where evidence gets fragmented across tools and manual review becomes the default.

That gap has an identity dimension as well. Release pipelines rely on human approvers, service accounts, automation tokens, and increasingly AI-assisted workflows, so governance fails when the identity behind each action is unclear or loosely controlled. For identity and security teams, this is a familiar pattern: if access, approval, and evidence are not bound into the workflow, compliance becomes reconstruction rather than control.

From our research: [72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirming one and 26% suspecting one.](https://nhimg.org/2024-esg-report-managing-non-human-identities) That level of exposure is why release governance and identity governance now overlap in practice, not just in theory.

Key questions

Q: How should security teams implement AI release governance in software delivery pipelines?

A: Start by making governance executable inside the release workflow, not in a separate document trail. Teams should classify AI changes, enforce policy gates, require role-based approvals, and capture evidence automatically as part of deployment. The goal is a release record that proves what was checked, who approved it, and why the change was allowed.

Q: Why do spreadsheets and manual reviews fail for EU AI Act readiness?

A: They fail because they cannot reliably prove that the required controls actually ran before production. Manual processes fragment approvals, policy decisions, and evidence across tools, so audit teams must reconstruct the story after the fact. That is too weak for regulated AI delivery, where traceability and accountability need to be built into execution.

Q: What signals show that an AI governance programme is not working?

A: Warning signs include disconnected models built by different teams, repeated disputes over data ownership, inconsistent approvals and outputs that cannot be explained to stakeholders. If the organisation cannot trace which data supported a decision or who approved the model, governance is already failing at the operating level.

Q: Which control matters most when AI changes need to be audited?

A: The most important control is a workflow that binds approval, policy results, and deployment evidence to the release object itself. That creates a durable chain of custody across tools and roles, which is what auditors, security teams, and compliance officers need when AI changes affect production systems.

Technical breakdown

Policy-as-code in release orchestration

The article describes a release orchestration layer that can evaluate policy rules inside the delivery workflow rather than outside it. In technical terms, this means gates can consume inputs such as vulnerability scores, approvals, signatures, artifact provenance, and tool results before allowing a deployment to proceed. The important shift is from after-the-fact review to enforced control points that travel with the release. For AI-enabled systems, that matters because the change may involve prompts, models, data pipelines, or generated code, all of which need different evidence and approvals.

Practical implication: teams should map AI release gates to explicit policy checks, not informal approval steps.

Traceable human oversight and role-based approvals

Human oversight in this context is not a meeting note or a spreadsheet sign-off. It is a workflow property that records who approved what, when they approved it, what role they acted under, and why the change was allowed. RBAC and routing rules matter because higher-risk AI changes often need a different approver than routine software changes. This creates a traceable decision trail that supports compliance, audit, and accountability. Without that binding between identity and approval, oversight is only implied, not provable.

Practical implication: bind release approvals to role-based routing, timestamps, and rationale capture.

Evidence capture across CI/CD, ITSM, and GitOps

The article’s strongest technical point is that release evidence should be produced during execution, not reconstructed later from multiple systems. That means approvals, scan outputs, deployment metadata, policy results, rollback criteria, and exception notes need to be persisted as part of the workflow. When evidence is spread across Jira, Jenkins, Git, Argo CD, security tools, and change tickets, audit teams end up rebuilding the story manually. Orchestrated evidence capture reduces that reconstruction burden and gives compliance teams a single release record.

Practical implication: require every AI-enabled release to emit a complete evidence bundle before production.

Threat narrative

Attacker objective: The objective is not only unauthorized access, but the ability to push ungoverned AI-related change into production without leaving a trustworthy audit trail.

1. Entry occurs when AI-enabled changes move through disconnected delivery tooling without enforced release controls, leaving governance dependent on manual review and inconsistent documentation.
2. Escalation happens when approvals, scan results, artifact lineage, and exception handling are fragmented across tools, making it difficult to prove who authorised the change and under what conditions.
3. Impact is governance failure: the organisation cannot reliably demonstrate EU AI Act readiness, trace release decisions, or reconstruct what was deployed and why.

NHI Mgmt Group analysis

EU AI Act readiness is becoming a delivery-control problem, not a documentation problem. Spreadsheets and post hoc review cannot prove that the right checks ran before production. The article reflects a broader shift in governance: if controls are not executable in the pipeline, they are not reliably enforceable. Practitioners should treat release orchestration as part of compliance architecture, not as an operational afterthought.

Release orchestration creates a new identity governance boundary around AI change. Each approval, exception, and deployment step is an identity event, whether it is performed by a human approver, a service account, or an automated workflow. That is where IAM and NHI governance meet software delivery. The named concept here is delivery-plane governance debt: the growing gap between policy intent and the ability to prove control execution in the pipeline. Practitioners should close that gap before AI change volumes make manual evidence reconstruction unmanageable.

Auditable AI governance depends on binding approvals to the release object itself. If the evidence lives in separate systems, the control cannot survive an investigation, an audit, or a dispute. This is a classic governance weakness in modern delivery: the control exists only as long as the team remembers how to reconstruct it. Security and compliance teams should require release records that travel with the artifact, environment, and approval chain.

The most useful AI governance controls are the ones that can fail closed. Policy checks, provenance validation, and environment restrictions only matter if they block release when required conditions are missing. That does not eliminate judgment, but it does make risk visible and actionable. Practitioners should prioritise controls that turn AI policy into enforceable release conditions, not advisory guidance.

As AI systems spread through software delivery, identity controls become evidence controls. The same governance discipline used for privileged access, secrets, and service accounts now needs to cover release approvals and deployment authorisation. That alignment is where compliance, security, and IAM can stop operating as separate programmes. Practitioners should design AI release governance as an identity-backed control model, not a separate checklist.

What this signals

Delivery governance is becoming part of identity governance. As AI changes move through CI/CD and GitOps, the identity of the approver, the service account, and the automation path matters as much as the technical change itself. Practitioners should expect stronger expectations for traceable approvals, signed artifacts, and auditable exception handling across the delivery stack. That is where the Secret Sprawl Challenge becomes relevant to AI release operations as well as classic NHI management.

Release evidence will increasingly be treated as control evidence. Organisations that cannot prove what was deployed, where, when, and by whom will struggle to satisfy both security reviewers and compliance assessors. The practical response is to align pipeline evidence with control frameworks such as NIST Cybersecurity Framework 2.0 and, where AI-specific governance is in scope, the EU AI Act regulatory framework.

Delivery-plane governance debt: this is the gap between AI policy intent and the ability to enforce that policy inside the release path. The longer that gap persists, the more organisations will rely on manual reconstruction, which is slow, inconsistent, and difficult to defend during audit or incident review. Security and identity teams should treat that debt as a programme risk, not a tooling inconvenience.

For practitioners

• Classify AI-enabled releases Identify whether each change touches a model, prompt, data pipeline, inference service, AI-generated code path, third-party AI service, or AI-enabled user experience before it enters the pipeline.
• Codify release gates as enforceable policy Use policy rules to gate deployment on required approvals, signed artifacts, provenance checks, vulnerability thresholds, and environment restrictions rather than relying on manual reviews.
• Bind approvals to named roles and timestamps Capture who approved the release, what role they acted under, when the decision was made, and why the exception was accepted so oversight is provable later.
• Automate evidence capture during execution Persist approvals, policy results, scan outputs, deployment targets, exception rationale, and rollback decisions as part of the release record instead of reconstructing them after the fact.

Key takeaways

• EU AI Act readiness depends on whether controls are enforceable in the release pipeline, not whether policy exists on paper.
• When approvals, provenance, and evidence are fragmented across tools, compliance becomes reconstruction and audit confidence drops.
• Identity, secrets, and release governance are converging around the same problem: proving who changed what, under which control, before production.

Key terms

• Release Orchestration: Release orchestration is the controlled coordination of approvals, checks, deployments, and rollback decisions across multiple tools. In governance terms, it turns a release into an auditable workflow rather than a collection of disconnected actions, which is increasingly important for AI-enabled systems that need traceability and accountability.
• Delivery-Plane Governance Debt: Delivery-plane governance debt is the growing gap between policy intent and the ability to enforce and prove that policy inside CI/CD or GitOps workflows. It appears when controls exist in documents or spreadsheets, but the actual release path cannot capture evidence, approvals, and exceptions reliably.
• Evidence Capture: The process of recording operational proof that a control was enforced at the time an action occurred. For AI governance, this includes identity, policy decisions, model versioning, access records, and execution outcomes in a form auditors can query later.
• Human Oversight: Human oversight is the requirement that a person remains responsible for reviewing, approving, or correcting AI-driven output before it causes a material action. In governance terms, it is the control that prevents automation from becoming unowned authority.

What's in the full article

Arxan Technologies' full blog post covers the operational detail this post intentionally leaves for the source:

• How Digital.ai Release embeds policy checks, approvals, and provenance validation into CI/CD and GitOps workflows.
• The specific evidence objects captured during execution, including scan results, deployment metadata, exception rationale, and rollback criteria.
• How the release orchestration model maps AI changes to classifications such as model, prompt, data pipeline, or AI-generated code path.
• The operational controls used to structure human oversight, including role-based routing, timestamps, comments, and audit reports.

👉 The full Arxan Technologies post covers release orchestration, evidence capture, and governance controls for AI delivery.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives security and identity practitioners a practical foundation for governing access, evidence, and lifecycle control.