AI Development, Security, and Compliance: GDPR, SOC 2, and PCI DSS in Practice
Date Published
An AI wrote the code, so who is responsible when it mishandles personal data? You are. Compliance obligations attach to the software and the business running it, never to the tool that generated the code. GDPR, PCI DSS, and SOC 2 apply exactly as they would if a human had typed every line.
That single fact is the one most buyers and vendors get wrong about AI-assisted development. The speed is real, but it changes none of the rules. What follows walks through the three frameworks a growing business hits most often, what each actually requires, and why "the AI wrote it" is not a defense any regulator or auditor accepts. Read it as vendor-evaluation guidance, not legal advice; confirm the specifics with your own counsel or data protection officer. For where compliance sits in the wider practice, start with vibe coding and AI-assisted development.
The Rule Nobody Can Prompt Their Way Around
Regulations regulate outcomes, not authorship. When your software stores a customer's address, processes a card payment, or handles employee records, the obligation lands on you as the operator of that software, whoever or whatever produced the code.
This matters more with AI in the mix, not less, because unreviewed AI code fails in exactly the ways compliance frameworks exist to prevent. Veracode's 2025 GenAI Code Security Report found 45% of AI-generated code samples carried known security vulnerabilities. A missing input validation or a hardcoded credential is a bug in any codebase. In one that handles personal or payment data, the same bug is a compliance failure with a reporting deadline and a fine attached. Speed of generation does not shrink that exposure; skipping review widens it.
GDPR: The Framework Most Businesses Hit First
The General Data Protection Regulation (GDPR) governs any software that handles the personal data of people in the EU, wherever the business itself sits. If your app stores names, emails, addresses, or behavior, GDPR applies, and using an AI to build it changes nothing about that.
Two obligations shape how the software has to be built. First, data protection by design and by default: security and privacy have to be engineered in from the start, not bolted on after launch. Unreviewed AI code fails this test structurally, because nobody decided how personal data would be protected; the model just produced something that ran. Second, breach notification. Under Article 33, a personal data breach that poses a risk to individuals must be reported to the supervisory authority without undue delay and, where feasible, within 72 hours (GDPR Article 33). A codebase no one understands makes that deadline brutal: you cannot report what happened if nobody can read the code to find out.
The stakes are set high on purpose. For the most serious violations, GDPR fines reach up to €20 million or 4% of total worldwide annual turnover, whichever is higher (GDPR Article 83). The way to stay clear of that is unglamorous: personal data handled deliberately, by code a human reviewed, with the data flows documented well enough to answer a regulator's questions.
PCI DSS: The Moment You Touch Card Payments
The Payment Card Industry Data Security Standard (PCI DSS) applies to any organization that stores, processes, or transmits cardholder data, regardless of size (PCI Security Standards Council). A one-person shop taking card payments is in scope the same way a bank is. The current version is v4.0.1, and its full set of requirements is mandatory as of 2025, so there is no grandfathering left to lean on.
The standard's requirements read like a checklist that unreviewed AI code fails item by item: encrypt cardholder data, restrict who can access it, test security regularly, log and monitor access. None of that happens by accident in a vibe-coded checkout. The safest architecture is also the simplest to comply with: do not store card data yourself at all. Route payments through a compliant payment gateway so the card details never touch your database, which shrinks your PCI scope to the integration rather than the whole system. That is a deliberate design decision a human makes, and it is exactly the kind of call that gets skipped when nobody reviews the build. It is also why payment flows are a review-heavy zone in our custom ecommerce development work.
SOC 2: When Your Customers Audit You
SOC 2 is different in kind from the other two. It is not a law and not a government certification. It is an auditing framework from the American Institute of Certified Public Accountants (AICPA), built on five Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy (AICPA). An independent auditor examines your controls and produces an attestation report. You do not "pass" SOC 2; you receive a report that your customers, usually larger companies vetting a vendor, read before they trust you with their data.
For a growing software business, SOC 2 tends to arrive as a sales requirement: an enterprise customer will not sign until you can show the report. Getting there rests on the same foundation as the other two frameworks. You need controls that actually exist, evidence that they run, and a codebase whose behavior a human can vouch for. An attestation built on unreviewed AI output is an attestation built on sand, because the moment an auditor asks how a control is enforced in the code, someone has to be able to read the code and answer.
What Ties All Three Together: A Human Who Read the Code
The three frameworks look different on paper and rest on the same foundation underneath. Each one assumes a person can explain how the software handles sensitive data, prove a control is really in place, and fix a problem when it surfaces. Every one of those assumptions breaks the instant the code is unread.
That is why review is not a compliance nicety but the load-bearing practice. A senior engineer reading every line is what turns "the app seems to work" into "we know how personal data flows, where card data does not go, and which control enforces which requirement." We cover what that review catches in human review of AI-generated code, and the security tooling around it, dependency scanning on every build and the rest, on how we secure every build. The point for compliance is narrow and firm: you cannot certify, report on, or defend code that nobody has read.
What to Ask an AI Development Vendor About Compliance
Bring these to a scoping call and listen for specifics.
- Who is responsible for compliance in the contract? The honest answer names you as the data controller and the vendor as a processor with defined obligations, not a vague promise that "everything is compliant."
- How is personal data handled in the architecture? You want a described data flow, not a reassurance. Where is data stored, who can reach it, and what is logged?
- Does card data ever touch the database? For anything with payments, the right answer is usually no, with a compliant gateway named.
- Who reviews the code, and can they answer a regulator's or auditor's questions about it? If no human can read the codebase and explain a control, no certification built on it is worth anything.
- Where does my data go when the AI generates the code? The vendor sends your codebase and sometimes your data to a hosted model. Ask which one, under what terms, and whether production data ever transits it.
Our full build pipeline, from written scope to reviewed handover, is documented in how we scope, build, and review, and it is built so these questions have plain answers.
Frequently Asked Questions
Is AI-generated code GDPR compliant?
Not by default, and GDPR compliance is never a property of code alone. It depends on how the software handles personal data: protection engineered in from the start, documented data flows, and controls a human can vouch for. AI can generate compliant code once an engineer reviews and verifies it.
Does using AI to build software remove my compliance obligations?
No. Obligations attach to the software and the business operating it, not to the tool that wrote the code. GDPR, PCI DSS, and SOC 2 apply exactly as they would to human-written software. "The AI wrote it" is not a defense any regulator or auditor accepts.
Do I need to be PCI DSS compliant if AI built my checkout?
Yes, if the software stores, processes, or transmits cardholder data, regardless of who built it or how. The lowest-risk path is routing payments through a compliant gateway so card data never touches your database, which shrinks your PCI scope to the integration.
Can vibe-coded software pass a SOC 2 audit?
Only if the controls behind it genuinely exist and someone can prove they run. SOC 2 is an independent attestation, not a checkbox. An auditor will ask how a control is enforced in the code, and unreviewed code leaves no one able to answer, so the attestation fails.
What is the biggest compliance risk with unreviewed AI code?
That a security flaw the model copied from its training data, present in 45% of samples in Veracode's 2025 study, ships into software handling personal or payment data. A bug becomes a breach with a 72-hour reporting deadline and a fine, instead of a comment caught in review.
How does Globaprom handle compliance in AI-assisted builds?
Compliance requirements get scoped and priced upfront, personal and payment data flows are designed deliberately, and a senior engineer reviews every line so controls can be proven. We are not your legal advisor, so we work alongside your counsel or DPO rather than in place of them.
Build It Compliant From the First Commit
Compliance is cheapest and safest when it is designed in, not discovered after launch. Tell us which regulations your software has to meet and we will scope them explicitly, build with every line reviewed, and hand you a codebase you can actually stand behind in front of a regulator or auditor.