The Hook

Your organization is SOC 2 Type II certified. You've invested years in building documented controls for data security, availability, processing integrity, and confidentiality. Every control is a documented procedure: someone does something, that something is recorded in an audit trail, and there's a person clearly accountable for the outcome. Your last audit was clean. Your customers trust your security posture.

Now you're considering deploying GitHub Copilot for your development team. Copilot is an AI system that generates code suggestions based on context. Your developers would paste code snippets into Copilot, get suggestions, and integrate those suggestions into your codebase. The code would go to production through your normal CI/CD pipeline.

But your SOC 2 controls don't account for AI-generated code. Your code review process assumes humans wrote the code and humans are reviewing it for security. Copilot changes that assumption. Your SOC 2 auditor will eventually ask: "How does Copilot fit into your SOC 2-controlled development process? Who's accountable if Copilot-generated code has a vulnerability that gets into production? How do you document that code is AI-generated? What controls ensure AI-generated code meets security standards?"

You realize you don't have clear answers. This is the fundamental challenge of compliance frameworks in the AI era. The frameworks weren't designed with AI in mind. They assume humans make decisions, humans review code, humans prepare financial statements. Your job as an IT professional is to map AI tools to existing compliance requirements and determine what new controls are necessary to remain compliant while still capturing the productivity benefits of AI.

Purpose: Mapping AI to Compliance Without Stalling Innovation

Compliance isn't optional, and it's not a constraint to work around. But it's also not a reason to ban AI tools entirely. Your responsibility is to understand what compliance frameworks apply to your organization, how AI affects them, and what controls are necessary to use AI tools while remaining compliant. This is a structured assessment process, not guesswork.

This lesson teaches you how to conduct that assessment: how to understand what frameworks apply, what specific controls they require, how AI affects those controls, and what additional controls or documentation you need to deploy AI responsibly. You'll learn the major frameworks and their AI implications, how to assess specific tools for compliance, and how to document your compliance decisions.

Why This Matters for IT Professionals

Compliance is increasingly tied to AI governance. Auditors are asking about AI. Regulators are clarifying AI rules. Your organization's ability to adopt AI tools responsibly depends on your ability to assess compliance. If you can't articulate how your AI deployment meets compliance requirements, you can't deploy it. If you can articulate it clearly, you can move forward confidently. The difference is professional competence in compliance assessment.

Core Concepts: How to Think About Compliance and AI

Key Insight: Compliance Frameworks Aren't Optional, But They Predate AI

Most organizations operate under one or more compliance frameworks. These frameworks have specific requirements about how you manage systems, data, and processes. SOC 2 requires controls around security and availability. ISO 27001 requires an information security management system. HIPAA requires specific protections for healthcare data. GDPR requires specific protections for personal data. PCI-DSS requires specific protections for payment card data.

When AI enters the picture, these frameworks don't have explicit "AI clauses" that clearly state what you must do. You have to interpret the existing clauses in light of AI and determine what they mean for AI deployment. This requires translating: "If our existing framework requires documented, auditable processes with clear accountability, how does that apply when AI is making some decisions or generating some outputs?"

The good news: existing frameworks generally still apply to AI. The bad news: they require interpretation and often require new controls you didn't need before.

Key Insight: Different Frameworks Focus on Different Risks

Different compliance frameworks focus on different risks because they were designed for different purposes and industries:

• SOC 2 focuses on operational controls (security, availability, processing integrity)
• ISO 27001 focuses on information security management
• HIPAA focuses on healthcare data protection (very strict)
• GDPR focuses on personal data rights (very prescriptive)
• SOX focuses on financial reporting accuracy and internal controls
• PCI-DSS focuses on payment card data protection (very technical)
• NIST AI RMF focuses on AI governance specifically (new, emerging standard)

When evaluating an AI tool, you need to know which frameworks apply to your organization and what they require. A tool might be fine for one framework and problematic for another.

SOC 2 and AI: Processing Integrity and Confidentiality

SOC 2 (Service Organization Control 2) is an audit standard for service organizations. It requires controls around security, availability, processing integrity, confidentiality, and privacy.

How AI affects SOC 2:

Processing integrity becomes complicated with AI. SOC 2 requires that transactions are accurate, complete, and authorized. But if AI is generating code or making decisions, how do you ensure accuracy?

If Copilot generates code with a vulnerability, is that a processing integrity failure? Who's accountable, the developer or Copilot? SOC 2 auditors will ask these questions.

The control you need: AI-generated outputs must be reviewed before deployment. The review process should be documented. Responsibility should be clear (the human reviewer, not the AI, is accountable for accuracy).

Confidentiality is affected if AI tools are processing customer data. If your SOC 2 audit includes customer data security, and you're using an unapproved AI tool, you're creating a control gap.

The control you need: AI tools used to process sensitive data must have documented data handling agreements that align with your SOC 2 commitments.

ISO 27001 and AI: Asset Management and Access Control

ISO 27001 is an information security management system standard. It requires controls around asset management, access control, cryptography, physical security, and incident management.

How AI affects ISO 27001:

Asset management becomes unclear. Is an AI tool an asset? Who's responsible for its security? If GitHub Copilot is used to develop code, is Copilot an asset that should be inventoried and managed?

The control you need: Document which AI tools are used, where they process data, and who's responsible for their security and compliance. Add them to your asset inventory.

Access control is affected if AI tools have access to sensitive systems or data. If developers use Copilot to write code that manages customer databases, Copilot (indirectly) has access to customer data.

The control you need: AI tools should have the same access controls as humans. If a developer can't see production data, the AI tools they use shouldn't see production data either.

Incident management must account for AI-related incidents. If an AI tool causes a security incident (generates vulnerable code, exposes data, makes a wrong decision), how do you document and respond?

The control you need: Incident response procedures should include AI-related scenarios.

HIPAA and AI: Business Associate Agreements

HIPAA (Health Insurance Portability and Accountability Act) governs healthcare organizations' handling of Protected Health Information (PHI). It's one of the strictest compliance frameworks because it involves patient data.

How AI affects HIPAA:

Using any unapproved AI tool to process PHI is a violation. Period. HIPAA-covered entities and business associates can only use tools with a Business Associate Agreement (BAA). A BAA is a contract where the vendor agrees to meet HIPAA security and privacy standards.

The control you need: Any AI tool processing PHI must have a signed BAA. Consumer tools like ChatGPT don't have BAAs and shouldn't be used for PHI. Period. No exceptions.

Additionally, HIPAA requires audit logs. If an AI tool is processing PHI, you need to know when, where, what data was processed, and by whom.

The control you need: AI tools processing PHI must have audit logging that meets HIPAA requirements. Every interaction should be logged.

SOX and AI: Financial Process Controls and Documentation

SOX (Sarbanes-Oxley) applies to publicly traded companies. It requires controls around financial reporting, internal audit, and management certification of financial statements.

How AI affects SOX:

AI in financial processes creates control gaps. If an AI tool is helping prepare financial statements, reconciliations, or audit documentation, how do you ensure the financial data is accurate? GAAP (Generally Accepted Accounting Principles) assumes humans are responsible for financial reporting. AI complicates that.

When an AI tool prepares a reconciliation, auditors ask: "Who prepared this? How was it reviewed? Is accuracy guaranteed?" If you can't answer these questions clearly, you have a control gap.

The control you need: Any AI use in SOX-controlled processes must be documented. Responsibility and accountability must be clear. The human accountant is still responsible for accuracy, not the AI. The AI is a tool the human used, not a replacement for human judgment.

Additionally, SOX requires change management. If you're changing how financial data is processed (by introducing AI), that's a change that needs to be documented and approved.

The control you need: Document AI introduction into financial processes as a change. Get audit approval. Ensure the process is documentable and repeatable for future audits.

PCI-DSS and AI: Payment Card Data Security

PCI-DSS (Payment Card Industry Data Security Standard) applies to organizations that process, store, or transmit payment card data.

How AI affects PCI-DSS:

Using AI tools to process payment card data is extremely risky. If an AI tool sees a credit card number, expiration date, or CVV, you're creating a PCI-DSS violation. Full stop.

The problem: developers might paste code examples that include sample payment card data, or use AI to help process payment data, and not realize the data security implications.

The control you need: AI tools should never process payment card data. Period. If they're being used in a payment processing system, they should only see tokenized or encrypted payment information, not raw card data.

Additionally, PCI-DSS requires specific security controls (encryption, access control, testing). If an AI tool is part of your payment processing system, it must meet PCI-DSS requirements.

The control you need: Any AI tool in a PCI-DSS environment must be security-reviewed and approved for that environment. Document its compliance with PCI-DSS.

NIST AI Risk Management Framework: The Emerging Standard

The NIST AI RMF (released in 2023) is the first U.S. government framework specifically for AI governance. It's rapidly becoming the de facto standard for AI compliance and is being referenced in other regulatory frameworks.

NIST AI RMF has four functions:

Govern: Establish policies, accountability, and oversight for AI systems.

This means: Do you have an AI governance policy? Who's accountable for AI compliance? What's the approval process for new AI tools? Is there executive oversight of AI risks?

Map: Identify and characterize AI systems and their risks.

This means: You need to know what AI tools are being used, what data they process, what risks they create, and who's responsible for them. This is your AI inventory and risk assessment.

Measure: Monitor and measure AI system performance and risks.

This means: After deploying an AI tool, how do you measure whether it's meeting compliance requirements? How do you detect when an AI tool is creating risks? What metrics matter?

Manage: Implement controls to mitigate AI risks.

This means: What controls prevent data leakage? What processes ensure AI outputs are accurate? How do you handle AI system failures?

For IT organizations, NIST AI RMF is becoming the framework for AI governance. Understanding its four functions helps you think about compliance comprehensively.

EU AI Act Basics: The Regulatory Future

The European Union is implementing the AI Act, which will regulate AI systems sold or used in the EU. While it's not yet fully enforced, understanding its basic structure helps with global compliance.

The AI Act categorizes AI systems by risk:

Prohibited risk: AI systems that are inherently harmful (facial recognition for mass surveillance, social scoring systems). These are banned.

High-risk: AI systems that require approval and governance before deployment (recruiting systems, resume screening, access control recommendations). These require documentation, testing, and ongoing monitoring.

Limited risk: AI systems with specific transparency requirements (chatbots used for customer service). These require disclosure that users are interacting with AI.

Minimal risk: AI systems with minimal regulatory requirements (spam filters, email assistants). These have minimal compliance burden.

Generative AI falls into the high-risk or limited-risk categories depending on how it's used. The AI Act requires documentation of what training data was used, how the system works, and what risks it creates.

For IT organizations, the AI Act signals that AI governance is becoming regulated. What's currently optional will become mandatory in EU jurisdictions.

Mapping AI to Compliance Requirements: Practical Examples

Here's how to think about AI in compliance frameworks:

Example 1: Using ChatGPT in a SOX-Controlled Financial Process

Scenario: Your financial planning team uses ChatGPT to summarize quarterly earnings for internal reporting.

Compliance question: SOX requires documentation of who prepared financial summaries and how they were reviewed. Does "ChatGPT prepared it" meet SOX documentation requirements?

Mapping: SOX controls assume human responsibility. If an AI tool is involved, you need to document:

• Who decided to use AI?
• What specific instructions were given to ChatGPT?
• What was the input data?
• How was the output reviewed?
• Who is accountable for accuracy?
• Is there a human reviewer who confirms the AI output before it becomes part of the financial record?

Control: Document AI use in SOX processes. Have a human reviewer who's accountable for accuracy. Document the process for auditors.

Example 2: Using Copilot in a PCI-DSS Payment Processing Environment

Scenario: Your development team uses GitHub Copilot to write code for a payment processing system.

Compliance question: PCI-DSS requires that code meets security standards. Does code generated by Copilot meet PCI-DSS standards?

Mapping: PCI-DSS controls include secure code review. If code is AI-generated, does it still need the same review? Yes, and possibly more careful review because AI-generated code has specific risks (hardcoded credentials, insecure patterns, vulnerable libraries).

Control: Require security review of Copilot-generated code. Document that code was reviewed for PCI-DSS compliance before deployment. Ensure developers understand that AI-generated code still needs security review, in fact, more careful review than human-written code.

Example 3: Using Claude in a HIPAA Healthcare Environment

Scenario: Your healthcare organization considers using Claude to help draft clinical documentation templates.

Compliance question: HIPAA requires that any tool processing PHI has a Business Associate Agreement (BAA). Claude's consumer version doesn't have a BAA.

Mapping: Claude Enterprise (not consumer Claude) might have a BAA available. But you need to verify the BAA before using it. You need to confirm:

• Does the vendor offer a BAA?
• Does the BAA cover all your use cases?
• Are there restrictions on what data can be processed?
• What's the vendor's incident response process?

Control: Only use HIPAA-compliant AI tools for PHI. Get vendor commitment to BAA before deploying. Document BAA in your compliance files. Have a process for staying informed of any changes to the BAA or the vendor's HIPAA compliance status.

How to Conduct an AI Compliance Assessment

When you're considering an AI tool, follow this systematic process:

Step 1: Identify the Data

What data will the AI tool process? Is it:

• Customer data? (PII, account information, preferences)
• Employee data? (Compensation, performance, personal information)
• Payment card data? (Credit cards, bank accounts)
• PHI? (Patient data, medical records)
• Financial data? (Revenue, transactions, pricing)
• Proprietary information? (Trade secrets, source code, strategies)

Step 2: Identify the Frameworks

What compliance frameworks apply to this data? (GDPR, CCPA, SOX, HIPAA, PCI-DSS, SOC 2, ISO 27001, NIST AI RMF, EU AI Act, or others?)

Step 3: Map to Controls

For each framework, what controls apply to how this data is handled? How do those controls account for AI?

Create a matrix:

• Rows: Compliance frameworks
• Columns: Control requirements
• Cells: How AI tool meets (or doesn't meet) each requirement

Step 4: Assess the Tool

Does the AI tool meet the compliance requirements? Ask the vendor:

• What data handling agreements do you offer? (DPA, BAA, etc.)
• What compliance certifications do you have?
• How does your tool meet specific control requirements?
• What documentation can you provide?

Step 5: Document the Decision

If you approve the tool, document why it's compliant. If you reject it, document why it's not. Document assumptions and requirements for ongoing compliance.

Anti-Patterns in AI Compliance Assessment

Risk: "Our compliance team will handle AI assessment"

Why it happens: You want to delegate to experts. Compliance is complex.

What goes wrong: Compliance teams can't assess AI tools alone. They don't understand the technical implementation or data flows. You get incomplete assessment or deployment delays.

How to avoid: Make AI compliance assessment a joint IT and compliance effort. IT brings technical expertise. Compliance brings regulatory knowledge. Together you create assessment that works.

Risk: "Vendor certification means we're compliant"

Why it happens: Vendors have SOC 2 certification. It's easy to assume that means you're good.

What goes wrong: Vendor certification is necessary but not sufficient. A vendor being SOC 2 certified doesn't mean their specific service meets your specific requirements. You need to verify.

How to avoid: Use vendor certification as a starting point, not an ending point. Ask: "What does your SOC 2 cover? Does it cover your AI services? Does it cover data residency? Does it cover my specific use case?"

Risk: "We'll assess compliance after deployment"

Why it happens: You want to move fast. Compliance assessment feels like it slows things down.

What goes wrong: Discovering compliance gaps after deployment is expensive and disruptive. You've already integrated the tool. Switching costs are high. You might need to do the deployment over.

How to avoid: Do compliance assessment before deployment. Yes, it takes time upfront. But it prevents rework and deployment delays later.

Risk: "Trust the vendor's compliance promises"

Why it happens: Vendor tells you they're compliant. Their sales team is convincing.

What goes wrong: Vendors have incentives to minimize compliance requirements. Their promised compliance might not be complete or might come with caveats and limitations.

How to avoid: Verify vendor compliance commitments in writing. Ask for documentation. Get legal review of their claims. Don't rely on verbal promises or sales presentations.

Examples: Compliance Assessment in Action

Example 1: Assessing ChatGPT for Finance Use

Scenario: Finance team wants to use ChatGPT to help with spreadsheet analysis and report summarization.

Framework Analysis:

• Applies: SOX (financial reporting), SOC 2 (processing integrity), possibly GDPR (if EU data)
• Doesn't apply: HIPAA (no healthcare data), PCI-DSS (no payment card data)

Compliance Assessment:

1. Data: What financial data will ChatGPT process? Revenue data? Customer financial data? Proprietary pricing?
2. SOX requirement: Financial statements must be prepared and reviewed with clear accountability. ChatGPT can assist, but a human must be accountable for accuracy.
3. Control: Train finance team that ChatGPT is a tool to assist, not replace human judgment. Humans review and approve ChatGPT outputs before they become part of official financial records.
4. Documentation: Document that ChatGPT was used, what it assisted with, and who reviewed the output.
5. Decision: Approve ChatGPT with guardrails, finance team can use for draft preparation and analysis, but humans must review and approve all financial statements.

Example 2: Assessing Claude for Healthcare Documentation

Scenario: Healthcare organization wants to use Claude to help draft clinical documentation templates.

Framework Analysis:

• Applies: HIPAA (healthcare data), state regulations (varies)
• Doesn't apply: GDPR unless EU patients, PCI-DSS unless payment data

Compliance Assessment:

1. Data: Claude would process Protected Health Information (PHI) to draft templates.
2. HIPAA requirement: Any vendor processing PHI must sign Business Associate Agreement (BAA). Consumer Claude doesn't have BAA.
3. Vendor Assessment: Is Claude available as enterprise service with BAA? Check Anthropic's offerings.
4. Control: If Claude Enterprise with BAA is available, can use it for healthcare. If not, can't use consumer Claude for PHI.
5. Decision: Only use Claude Enterprise (if BAA available) or find alternative that offers HIPAA-compliant service with BAA.

Human Judgment Checkpoints for Compliance

Checkpoint 1: Do you know which compliance frameworks apply to your organization?

If you don't know whether you're SOC 2, ISO 27001, HIPAA, GDPR, SOX, or PCI-DSS compliant, that's the starting point. Get clarity on your compliance landscape.

Checkpoint 2: Have you assessed the data that will flow through the AI tool?

What data will it process? Is it sensitive? Is it regulated? This determines which frameworks apply.

Checkpoint 3: Have you mapped the tool to compliance requirements?

For each applicable framework, do you understand what it requires and how the tool meets those requirements?

Checkpoint 4: Have you documented your compliance assessment?

Can you explain your compliance decision in writing? If you're audited, can you show your reasoning?

Checkpoint 5: Do you have compliance agreements in place?

For sensitive data, do you have DPA, BAA, or other compliance agreements signed before deployment?

Key Takeaways

• 
  Compliance frameworks weren't designed with AI in mind, but they apply to AI tools. You need to interpret existing controls in light of AI deployment. If a framework requires documented, auditable processes with clear accountability, that still applies to AI. It means you need to document how AI is being used and who's accountable for the outcome.
• 
  Different frameworks have different AI implications. SOX focuses on documentation and accountability in financial processes. HIPAA focuses on data handling agreements and audit trails. GDPR focuses on data rights. PCI-DSS focuses on data security. Know your frameworks; understand their specific requirements.
• 
  AI in compliance-controlled processes creates control gaps that auditors will find. If you're using AI in a SOX-controlled financial process or a HIPAA-controlled healthcare process, auditors will ask how you're maintaining control. Document your answer.
• 
  NIST AI RMF is emerging as the standard for AI governance. The four functions, Govern, Map, Measure, Manage, provide a framework for thinking about AI compliance comprehensively. Consider this as you build AI governance.
• 
  Data processing agreements (DPAs) and Business Associate Agreements (BAAs) are the technical tools for compliance. For regulated data, get these agreements signed before deployment. They're not optional.
• 
  Compliance assessment should happen before tools are deployed. Do it upfront. Yes, it takes time. But discovering compliance gaps after deployment is more expensive and more disruptive.
• 
  Make compliance assessment a joint IT and compliance effort. You need technical expertise and regulatory expertise working together. Neither can do it alone.