AI Coding Compliance: A Regulation-by-Regulation Mapping

Most of what’s written online about “AI coding compliance” is extrapolation — here is what SOC 2 probably wants, here is what HIPAA might care about. That’s not useful to a privacy lead whose auditor is on the calendar for Q3.

This post is the reference table. Five regulations, each mapped to the specific control requirements that AI-assisted code touches, the evidence artifact the auditor will ask for, and the audit-time sentence you should be able to say out loud without hesitation.

The entries aren’t legal advice, and the control numbering updates as each framework revises. Read with your compliance team, not instead of them. But when you want to know which bits of your AI governance stack feed which line in which control framework, this is the cross-reference.

How to Use This Table

Every row follows the same four columns:

• Control requirement — the specific clause or trust principle
• How AI coding touches it — why this control is now an AI question
• Evidence artifact — what the auditor will ask to see
• Audit-time answer — the sentence you should be able to say

Controls that are simply the same-as-before-AI (code must be reviewed, least privilege, etc.) are not repeated here. This table covers the incremental obligations AI introduces on top of your existing compliance posture.

SOC 2 (Trust Services Criteria 2017, AICPA)

Control requirement	How AI touches it	Evidence artifact	Audit-time answer
CC8.1 — Changes authorized, designed, developed, implemented	AI-assisted commits are a change mechanism; must be authorized	Provenance trailers on every commit; CI check rejecting missing trailers	”Every commit carries an AI-Assisted: trailer. Coverage is audited monthly and currently sits at X%.”
CC8.1 (b) — Documents changes	”Documentation” includes provenance of how the change was produced	Trailer fields: AI-Tool, AI-Model, AI-Prompt-Summary, Reviewed-by	”We retain tool, model, prompt summary, and reviewer identity for every AI-assisted change.”
CC7.2 — Monitors system components for anomalous behavior	AI-introduced defects are a class of anomaly	AI-specific SAST rules running in CI + production error monitoring tagged by provenance	”We have a ten-rule SAST pack tuned for AI-generated patterns; findings are triaged per our gating tree.”
CC1.4 — Commitment to competence	Developers using AI tools need competence in reviewing AI output	Mandatory AI-code-review training completion log; risk register R9 entry	”Every engineer who merges AI-assisted commits has completed the internal AI review course within the last twelve months.”
P4.2 — Personal information use limited by stated purposes	Pasting customer data into an AI prompt may exceed stated use	DLP logs on prompt paste events; enterprise-tier DPA with each tool vendor	”Approved tools carry zero-retention contractual commitments; DLP blocks customer PII at the clipboard boundary.”

HIPAA Security Rule (45 CFR §164.308–.312)

Control requirement	How AI touches it	Evidence artifact	Audit-time answer
§164.312(b) — Audit controls	AI-generated code touching PHI systems is an auditable activity	Provenance trailers retained ≥6 years; filterable query git log --grep="AI-Assisted:" scoped to PHI modules	”Every commit to a PHI-handling repository carries provenance metadata retained for the full six-year HIPAA period.”
§164.308(a)(1)(ii)(A) — Risk analysis	AI-generated code introduces new risks requiring analysis	Filled-in risk assessment updated quarterly with AI rows	”Our risk register treats AI-coding exposure as a distinct category; it is reassessed each quarter and reviewed by the CISO.”
§164.308(a)(3)(ii)(B) — Workforce sanctions	Misuse of AI tools (pasting PHI into prompts) is a sanctionable event	Written AI acceptable-use policy signed by every engineer; DLP violation → HR workflow	”Pasting PHI into an unauthorized AI tool is a Category-B sanction per policy §4.3, with escalation matrix defined.”
§164.308(a)(4) — Access management	AI tools are a form of system access; provisioning must be controlled	SSO-only tool provisioning; approved-tools allowlist; quarterly access review	”AI coding tools are provisioned via SSO from our identity provider; no personal-account usage is permitted on PHI systems.”
§164.314(a) — Business associate contracts	AI tool vendors processing any PHI-adjacent data are BAs	Executed BAA with each approved tool vendor OR contractual prohibition on PHI submission	”No approved tool is authorized to receive PHI; tools that cannot sign a BAA are excluded from the allowlist for PHI-handling teams.”

PCI-DSS v4.0 (March 2022, transition period through 2025)

Control requirement	How AI touches it	Evidence artifact	Audit-time answer
6.2.1 — Bespoke and custom software developed securely	AI-assisted code is bespoke software under PCI scope	SAST rule pack run at merge; evidence of rule coverage for injection, auth bypass, crypto misuse	”Our secure-development lifecycle includes an AI-tuned SAST pack covering the attack classes identified in 6.2.4.”
6.2.3 — Bespoke software reviewed prior to release	Review must be effective; AI code requires AI-aware reviewers	Provenance trailer field Reviewed-by; reviewer-training record; gating decision tree	”Every AI-assisted change in CHD scope is reviewed by a trained second engineer; Reviewed-by trailer is enforced at CI.”
6.2.4 — Review addresses injection, buffer overflow, insecure crypto, insecure auth, insecure data storage, insecure logic	These are precisely the categories AI fails on	SAST rule mapping — R-002 injection, R-004 deserialization, R-005 JWT, R-009 crypto, R-006 error leak	”Each 6.2.4 category maps to one or more rules in our AI-tuned SAST pack; finding counts are tracked in the change-management dashboard.”
12.10.5 — Incident response includes relevant detection systems	AI-specific detection (SAST + provenance) must be part of incident triage	Runbook step: “Query git log for AI-Assisted commits in affected paths”; git log --grep output retained per retention policy	”Our incident response runbook includes an AI-provenance triage step; the query is scripted and retained per incident.”
8.3.6 — Strong cryptography	AI-generated crypto defaults to weak primitives (R-009)	SAST rule R-009 blocking deprecated primitives; crypto module under CODEOWNERS gate	”Cryptographic primitives can only be introduced by commits approved by the security team; deprecated primitives are blocked at SAST.”

GDPR (EU 2016/679)

Control requirement	How AI touches it	Evidence artifact	Audit-time answer
Art. 5(2) / Art. 24 — Accountability	Organization must be able to demonstrate compliance of AI-involving processes	Written AI governance policy; risk assessment; trailer coverage report	”We can produce, on request, the governance policy, current risk assessment, and evidence of our control implementation for AI-assisted development.”
Art. 25 — Data protection by design	AI prompts that include personal data create a processing activity	DLP on prompt-paste vectors; approved-tool enterprise-tier contracts	”Personal data cannot reach approved AI tools via standard developer workflows; DLP blocks at the clipboard boundary, and approved tools carry zero-retention commitments.”
Art. 28 — Processor obligations	Any AI tool that processes personal data is a processor requiring a DPA	Signed DPA per approved tool vendor; vendor risk assessment	”Every approved tool has an executed DPA on file with the Privacy Office; no personal data reaches tools without one.”
Art. 30 — Records of processing	AI-involving processing activities must appear in the ROPA	Entry in ROPA for each approved AI coding tool with purpose, categories, retention	”Our ROPA includes a dedicated entry for AI coding assistance with the legal basis, tool vendor, and retention position.”
Art. 32 — Security of processing	Controls for AI-generated code security	SAST ruleset + gating tree + provenance trailers	”Our technical measures for AI-assisted development are the ruleset, gating tree, and provenance trailers — each documented in the security policy.”

EU AI Act (Regulation 2024/1689, applying 2025–2027)

The AI Act regulates providers and deployers of AI systems. For most software companies, using AI coding tools makes you a deployer of a general-purpose AI system rather than a provider of a high-risk one — but deployer obligations still apply, and if your product embeds AI, you may simultaneously be a provider of a separate high-risk system. This table covers the deployer side.

Control requirement	How AI touches it	Evidence artifact	Audit-time answer
Art. 26(5) — Human oversight of high-risk AI systems	If your AI coding workflow touches a system classified as high-risk (Art. 6), human review of AI output is mandatory	Provenance trailer field Reviewed-by + AI-Review-Confidence; gating tree routing	”All AI-assisted commits to high-risk system components are reviewed by a named human and carry a confidence indicator.”
Art. 26(6) — Logging	Deployers must retain logs of high-risk system operation for ≥6 months	Provenance trailers retained in git (effectively permanent); corresponding CI run logs	”All AI-involvement logs are preserved in git commit metadata plus retained CI run records, both exceeding the six-month minimum.”
Art. 50 — Transparency (general-purpose AI)	Outputs from general-purpose AI must be disclosed to end users where applicable	If AI-generated code is exposed to end users (e.g., a product feature), labeling per Art. 50(2)	“Our product does not expose AI-generated code directly to end users. Internal AI-assisted development is covered by the separate deployer disclosure in our privacy notice.”
Art. 4 — AI literacy	Staff using AI systems must have adequate literacy	Training program; completion records	”All engineers with AI tool access have completed the internal AI literacy program within the last twelve months; records are held in the LMS.”

How the Artifacts Stack

You’ll notice the same handful of artifacts appear in almost every row:

1. Provenance trailers — feed SOC 2 CC8.1, HIPAA §164.312(b), PCI 6.2.3, GDPR Art. 5(2), EU AI Act Art. 26(6).
2. AI-tuned SAST ruleset — feeds SOC 2 CC7.2, PCI 6.2.4, GDPR Art. 32.
3. Gating decision tree — feeds PCI 6.2.3, EU AI Act Art. 26(5).
4. Risk assessment document — feeds HIPAA §164.308(a)(1), GDPR Art. 5(2) accountability.
5. Tool DPAs / BAAs — feed HIPAA §164.314(a), GDPR Art. 28.
6. Training completion records — feed SOC 2 CC1.4, HIPAA workforce controls, EU AI Act Art. 4.

Build these six once. Each one covers multiple rows across multiple frameworks. If you find yourself building framework-specific controls rather than framework-independent artifacts mapped to multiple requirements, stop — you’re duplicating work.

What This Table Doesn’t Cover

Jurisdiction-specific overlays. NYDFS 500, California CCPA/CPRA, UK ICO guidance on AI, sector-specific regulations (FDA SaMD, FedRAMP Moderate/High, FINRA). These overlay on the frameworks above and frequently demand additional evidence. Add them as rows to the same table structure rather than as separate tables.

Customer-contractual obligations. Your MSAs and DPAs with customers may impose AI-use restrictions stricter than any regulation. These are usually under the Legal team’s remit; the CISO should get a flagged list of AI-restrictive clauses during any contract review cycle.

Product-level AI Act classification. Whether your product is a high-risk AI system under Annex III is a question for product counsel, not this table. The table assumes you are only a deployer; if you are a provider, obligations multiply considerably.

For the policy language that ties the table above into an enforceable internal standard, see the governance framework. For the scoring and investment prioritization that flows from the residual risk these controls leave behind, see the risk assessment template.