Victor Martin

Governance

Auditability and Compliance of AI-Assisted Development

AI coding agents write an increasing share of production code, and auditors, investors, and boards have started asking about it directly. This guide covers what gets asked, what a disciplined team already has as evidence, and what most teams are missing.

What an auditor or a due diligence team will ask

In a technology due diligence, a SOC 2 audit, or a board review, these questions come up whether or not AI is mentioned by name:

  • Who wrote this code, and who reviewed it, for any given commit.
  • What tests exist, and did they pass before this change reached production.
  • What data left the company, if any tool that touched the code also sent data to a third-party model.
  • Whether there is a written policy governing AI tool use, and whether anyone can show it is followed.

Evidence you already have if the harness is right

A team with a disciplined engineering practice, tests, CI, code review, is most of the way to being auditable without extra work, because the same trail that lets an agent verify its own work is the trail an auditor wants to see:

  • Commit history and pull request review, showing who approved every change.
  • CI logs, showing which checks ran and passed before merge.
  • Test coverage reports, showing what is actually verified, not just claimed.

Evidence you need to add

This is where most teams have a gap, because it is specific to AI-assisted work and rarely exists by default:

  • A declaration of AI use: a marker on commits or pull requests, or a simple log, showing where an agent was involved.
  • A model and tool inventory: which AI coding agents are in use, on what accounts, approved by whom.
  • Data classification for prompts: a record of what categories of data are allowed to reach which tools.
  • Retention of agent transcripts where your context requires it, for example under a client contract or a regulatory obligation.

Regulated contexts, in general terms

The specifics depend on your sector and jurisdiction, so treat this as a map of where to look, not legal advice. For financial entities in the EU, DORA covers ICT risk and third-party dependencies, which can include AI coding tools depending on how they are used. GDPR applies whenever prompts contain personal data, regardless of the tool. The EU AI Act's scope for internal developer tooling is narrow in most cases, but the classification depends on the specific use, so it is worth a specific check rather than an assumption. Always confirm current obligations with your legal and compliance team against the official texts.

A minimal audit checklist

Ten items that cover most of what gets asked:

  • Written AI coding policy exists and is dated.
  • Approved tools and accounts are listed and current.
  • Every production change has a named reviewer.
  • CI runs tests, linting, and security scanning on every change.
  • AI-assisted commits or PRs are identifiable in the history.
  • No secrets or credentials appear in prompts or agent context files.
  • Data classification rules exist for what can reach an AI tool.
  • Dependency and license scanning runs on AI-suggested code too.
  • A named owner reviews the policy on a set schedule.
  • Engineers can explain the code they merge, on request.

How this shows up in a technology due diligence

In a tech DD ahead of an investment or acquisition, this is no longer a theoretical question. Reviewers now ask directly how much of the codebase is AI-generated, what review process it went through, and whether the policy and the practice actually match. Teams that can answer clearly, with evidence, close faster and raise fewer flags than teams that have to guess.

Frequently asked questions

Does the EU AI Act apply to internal coding agents? ⌄

In most cases the classification for an internal developer tool is low-risk or out of scope, but this depends on exactly how the tool is used and what decisions it influences. Do not assume, check the current classification for your specific use with your legal team.

Do we need to keep every agent conversation forever? ⌄

No, retain what your contracts or regulator require and no more. Blanket retention of AI transcripts creates its own data risk. Define a retention period tied to the actual obligation, not a default of "keep everything".

What is the fastest way to close the gap before an audit? ⌄

Write the policy first, even a short one, then add the AI-use marker to your commit or PR template. Those two changes create most of the missing evidence going forward, though they do not retroactively cover past work.

Does this apply to a small team without a formal SOC 2 or audit yet? ⌄

Yes, and it is cheaper to build the habit early than to reconstruct it later. A due diligence team or a future auditor will ask for exactly this evidence, and a small team that already has it moves faster through that process.

Read next

Governance

An AI Coding Policy Template for Engineering Organizations

A short, copy-ready AI coding policy for engineering organizations: six points to cover, how to make them enforceable, and how to roll them out without a revolt.

Foundations

Agentic Engineering vs Vibe Coding

Vibe coding and agentic engineering both use AI to write code, but only one produces software you can put in production. Here is the distinction, and how to move a team to the disciplined side.

Foundations

What an AI Coding Agent Actually Is (and Isn't)

An AI coding agent is more than autocomplete and less than a senior engineer. This guide gives a clear definition, explains the loop that makes it an agent, and shows what it is not.

Get audit-ready without slowing your team down

Closing this gap is mostly about making existing discipline visible, not adding new bureaucracy. If you are heading into a due diligence, an audit, or a board review and want a straight assessment of where you stand, that is exactly what I do in advisory work.