Skip to content
Christoph Kassen

Strategic technology advisor / Cloud & AI / Munich

AboutServicesBlogContact
AboutServicesBlogContact
Back to Blog

Policy as Code: Governing Software in an Age of AI-Accelerated Development

Published on March 16, 20263 min read
DevSecOpsCompliancePlatform EngineeringCloud

One consequence of faster software development gets less attention: governance. Not security in the abstract, but the practical work of keeping compliance intact while code moves faster.

Most organisations still rely on manual gates. Security reviews a deployment. An architecture board approves a design. An auditor checks the configuration later. That worked when large changes happened slowly enough for a person to review each one.

That world is changing.

The velocity problem

AI tools help developers ship faster. A feature that took two weeks may now take three days. That is useful and, of course, the point.

A compliance process designed for two releases per sprint doesn't scale to eight. The compliance team grows, review quality drops, or people start skipping the checks.

None works for a regulated team, or any team serious about security. Slowing developers down isn't much of an answer. Making compliance programmable is.

What Policy as Code means

The idea is simple: express compliance requirements as code instead of prose. The policy lives in version control, gets reviewed like any other change, and runs during deployment.

A Kubernetes cluster can reject a deployment below the security baseline. CI can block an infrastructure change that violates cost or configuration policy and explain why. A service without the required logging cannot be provisioned.

The tooling is mature. Open Policy Agent covers Kubernetes admission control, API authorisation, and Terraform plan validation. Kyverno offers a more Kubernetes-native option with a lower barrier to entry. Both run in large production environments, so their failure modes are well understood.

The harder part

Choosing a tool is the easy part. Deciding what the policies should be, and keeping them current, is harder.

A good policy needs technical and compliance knowledge. Those usually live in different teams. A security engineer who hasn't deployed a container and a platform engineer who hasn't read the framework can easily talk past each other. Bridging that gap takes time.

Policies also become wrong or outdated. A manual gate allows judgment; code will keep blocking a legitimate deployment until someone changes it. You need an escape hatch, and it needs an audit trail.

Good teams treat compliance like a product. Someone owns the quality of the policies, not just their existence, and watches for rules that create more friction than they prevent.

Why this matters now

AI-assisted development produces more code across more surface area. That means more configuration drift, non-standard patterns, and accidental policy violations. The code isn't necessarily worse. There is simply more of it.

Policy as Code doesn't solve everything, but it scales with delivery speed. Manual review at the end of a pipeline won't.

The same applies to AI agents touching infrastructure. From a compliance perspective, an agent with permission to change configuration is a new actor. It needs the same programmable guardrails as a human engineer.

The direction is clear. The implementation isn't simple. If you're building governance for a faster team, I'm happy to compare notes.

If something here was useful or you're thinking through a related problem, feel free to get in touch.

Back to Blog