Notifications
Clear all
Topic starter
06/09/2026 9:02 am
TL;DR: EU AI Act readiness depends on proving that AI controls, approvals, and evidence were enforced during software delivery, not reconstructed after release, according to Arxan Technologies. The real governance gap is a delivery gap, where spreadsheets and disconnected reviews cannot reliably show what changed, who approved it, and whether the required oversight actually ran.
NHIMG editorial — based on content published by Arxan Technologies: Why EU AI Act Readiness Starts in the Software Delivery Pipeline
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read Arxan Technologies' analysis of EU AI Act readiness in the software delivery pipeline →
EU AI Act readiness and the governance gap in software delivery?
Explore further
06/09/2026 9:02 am
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.
A question worth separating out:
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.
👉 Read our full editorial: EU AI Act readiness starts in the software delivery pipeline
