by Jerrad Bartczak, IT Audit Manager, AI & Special Projects

AI in Your Compliance Program: What Change Management Looks Like When AI Tools Are in the Pipeline

AI is showing up in engineering workflows faster than most compliance programs are prepared for. As development teams use AI to review pull requests, flag risky changes, and speed up code reviews, this leaves compliance teams left asking the obvious question: does this break our change management controls, or can it actually strengthen them?

The short answer is that AI tools don’t replace change management requirements, they have to be incorporated into them. Frameworks like SOC 2 expect clear evidence that production changes are categorized appropriately and reviewed by the right people before they are deployed. Adding an AI tool into that workflow doesn’t remove that expectation. If anything, it raises the bar for what “evidence” needs to look like.

In working with clients navigating this exact question, we’ve found that a well-designed change management program built around AI-assisted development tends to share a few common characteristics.

Changes are categorized by risk, not left to ad hoc judgment.

Higher-risk categories: authentication, PII handling, cryptography, identity and access management, are treated differently than routine changes. That differentiation isn’t a general policy statement; it shows up in configuration, in tagging, in settings that can actually be pointed to as evidence.

Review rigor scales with risk.

Not every change needs the same level of scrutiny, but the changes that matter most, the ones touching production, auth, or sensitive data, need full human review before they can be merged. The key is that this threshold is clearly defined and consistently applied, not assumed.

AI tool involvement is itself auditable.

If an AI-assisted review tool is part of the pull request process, that involvement needs to be logged, not just described. Configuration settings and retained logs showing the tool ran on every pull request are what turn “we use AI for this” into something an auditor can actually verify.

Technical controls enforce the policy, they don’t just describe it.

Technical controls such as branch protection rules, required reviews, and blocked merges on failed checks are what make a policy real. A documented process that isn’t backed by matching technical enforcement is one of the fastest ways to create a gap between what a company says it does and what its systems actually do.

Policy and configuration have to match.

This is where most change management programs run into friction during an audit, not because the underlying practice is weak, but because the written policy and the actual system configuration have drifted apart. Keeping those aligned, and keeping evidence of that alignment on hand, is what makes the program defensible.

None of this requires slowing down engineering teams or treating AI tools with suspicion. It requires the same discipline compliance programs have always needed, clear documentation, consistent enforcement, and retained evidence, applied to a workflow that now includes AI in the loop.

As more compliance frameworks begin addressing AI directly, this kind of groundwork matters. Advantage Partners is currently accepting early partner clients as part of our work toward ISO 42001 and AIUC-1 readiness, helping organizations build AI governance practices that hold up under scrutiny from day one.

Interested in learning more about AI in technology environments from a compliance perspective? Read Part 1: Preparing Your Compliance Program for AI.