Compliance Mapping Matrix
Map SOC 2, HIPAA and GDPR controls to your AI usage — gaps surfaced explicitly.
control intersections across 4 activities × 2 regimes. Red cells are hard requirements; amber are strongly recommended practice.
| Activity | SOC 2 | GDPR |
|---|---|---|
| AI code generation | RequiredHuman review before merge; change-management trail covers AI-generated code. | RecommendedEnsure no personal data is pasted as context during generation. |
| Customer data in prompts | RequiredData-classification policy must explicitly govern prompts; vendor in scope of vendor review. | RequiredLawful basis + DPA required; provider appears in RoPA; verify residency commitments. |
| Agent tool execution | RequiredLeast-privilege tool allowlists; agent actions logged and attributable to a human owner. | RecommendedAgents touching personal data inherit processor obligations; log and minimize access. |
| Prompt/usage log retention | RequiredUsage logs retained per evidence schedule; protected as confidential audit material. | RequiredLogs with personal data need retention limits, minimization, and subject-rights handling. |
Not legal advice. This matrix distills common interpretations of each framework into planning shorthand — confirm every "required" cell with counsel and your auditor before relying on it.
How it works
Compliance conversations about AI tend to fail in one of two directions: either everything is treated as forbidden, or frameworks are waved at without anyone saying what they actually demand. This matrix builder forces specificity. Rows are the things your team concretely does with AI — code generation, customer data in prompts, fine-tuning on user data, agent tool execution, prompt-log retention. Columns are the regimes you select: SOC 2, ISO 27001, HIPAA, GDPR, the EU AI Act. Each intersection shows a requirement level and one sentence of control text from an embedded mapping, so the discussion starts from positions rather than vibes.
The requirement levels encode a practical triage. Required cells are hard obligations under the regime's text or its standard audit interpretation — the kind that block a launch. Recommended cells are expected practice with implementation latitude — the kind you should do by default and document if you deviate. Cells marked n.a. exist so the absence of an obligation is explicit rather than assumed. The hero number counts required intersections across your selection, which is a fair one-line summary of how much compliance work your AI usage actually implies.
Two rows deserve flagging. Customer data in prompts is the heaviest because it triggers every regime at once — transfer, processing and vendor risk in a single paste event. Agent tool execution is the fastest-growing: agents act under your credentials, and both SOC 2's access-control lens and the EU AI Act's human-oversight lens apply to what they autonomously do.
Export the matrix as markdown for your compliance workspace, and re-run it whenever the activity set changes — adopting fine-tuning or agents redraws the grid. The standing caveat is printed on the page and in the export: this is structured planning shorthand, not legal advice. Use it with the AI governance checklist, which turns the same regimes into a trackable control list, and with the usage policy generator when it is time to write the rules down.
Frequently asked questions
What does 'required' versus 'recommended' mean in the matrix?
Required marks intersections where the regime's text or its standard audit interpretation creates a hard obligation — a BAA before PHI enters a prompt under HIPAA, a lawful basis and DPA under GDPR, change-management evidence under SOC 2. Recommended marks practices auditors and regulators expect to see but where the framework leaves implementation latitude. Treat required cells as blockers and recommended cells as strong defaults you should justify deviating from.
Why is 'customer data in prompts' the heaviest row?
Because pasting customer data into a third-party AI service is simultaneously a data transfer, a processing activity and a vendor-risk event. Every selected regime reacts: GDPR demands a lawful basis and processor agreement, HIPAA demands a BAA for PHI, SOC 2 demands the vendor be in scope of your review program, and ISO 27001 pulls in classification and transfer controls. If you do only one thing from this matrix, govern that row first.
How does agent tool execution change my compliance picture?
Agents act with credentials, and frameworks treat actions taken under your credentials as your actions. SOC 2 and ISO 27001 expect least-privilege allowlists and attributable logs for what agents do; the EU AI Act adds a human-oversight expectation for consequential autonomous actions. The practical control is narrow scopes: an agent that can only touch the repos and APIs it needs converts an unbounded compliance question into a reviewable one.
Can I rely on this matrix instead of legal advice?
No, and the export says so explicitly. The matrix distills common interpretations of each framework into planning shorthand so engineering and compliance can have a structured first conversation. Real obligations depend on your contracts, jurisdictions, data types and the specific services involved. Use the matrix to find your exposure surface and prioritize, then validate every required cell with counsel and your auditor before treating it as settled.
How should I use the exported markdown matrix?
Paste it into your compliance workspace and turn each required cell into a tracked task with an owner. The matrix format works well in design reviews too: when a team proposes fine-tuning on user data, the relevant row shows in one glance which regimes activate and what each demands. Re-export whenever your activity set changes — adding agents or fine-tuning meaningfully reshapes the obligations grid.
Budgeting AI spend for a team? FORG is $15/dev with hard budget caps and per-seat attribution.
See FORG pricing