PCI DSS with AI: A Modern Approach to Security Compliance in Payment Systems
Table of contents
The biggest problem with compliance is that it grows old and irrelevant way too fast. In January, you submit your PCI DSS documents and relax, knowing you have a whole year before you have to do it again. Fast-forward to early fall, and you realize that you’ve added a new payment channel, expanded a service to another geo, and integrated with a few external systems. These new developments have changed everything, and that self-assessment questionnaire (SAQ) file that proved you were 100% compliant now describes something that no longer exists.
The cost and complexity of manual PCI DSS compliance generally comes from this ever-widening gap between the day your assessor last signed off and the current date. This is why the PCI DSS v4.0.1+ standard strongly advocates continuous, automated controls where AI agents can bring tangible value by reviewing logs, flagging suspicious activities, and checking configurations against requirements in 24/7 mode1.
But what if you are a merchant that already accepts card payments and wants to add an LLM model, a support agent, or a vendor-operated copilot to their payment system? In this case, the AI component becomes part of your compliance drill, and all of a sudden, you are dealing with data exposure, permissions, guardrails, and an expanded AI PCI compliance scope.
In this article, we'll focus on where AI sits on your compliance checklist, which requirements are relevant to it, and which safety measures you need to implement to keep sensitive data secure without sacrificing AI-based advantages.
Kyrylo Petrov, Director of Fintech Technology Consulting at Oxagile, shared some valuable insights from his multi-year career in designing fintech products and supervising their end-to-end implementation.
“I think the era of manual compliance and static spreadsheets is over or is about to be over. Your payment infrastructure never stops evolving, but a months-old snapshot of what it used to be stays frozen in time and loses relevance with every passing day.
And it’s not just my personal opinion. The latest version of PCI DSS actually points in the same direction: only continuously collected evidence helps you stay up to date between compliance audits.”
Key takeaways
- AI doesn't really have to touch card data to create a PCI issue. If an agent can change a firewall rule, access a payment service, or influence a security control, it can affect your PCI scope even if it never sees a customer’s card number.
- Don't spend all your time securing the model and forgetting everything else around it. Problems often hide in connection-related things: what the agent can access, which tools it can call through MCP, what credentials it uses, and where its activity gets logged, if at all.
- AI is amazing at finding gaps, however, it's not tantamount to evidence. An agent can flag a misconfiguration in seconds, but you still need to verify what it found and show that the control actually works.
- Give AI agents room to investigate, but limit what they’re allowed to change. They can collect evidence and flag issues autonomously, but security-sensitive actions require human approval.
What AI PCI compliance covers
AI governance in PCI DSS compliance is not a subject of a separate certification. Companies still apply relevant PCI DSS requirements to AI systems and rely on official PCI SSC guidance for efficient risk management.
In terms of functionality, AI has two major touchpoints with PCI DSS:
- Companies can use artificial intelligence as a compliance Swiss army knife to continuously analyze infrastructure, spot gaps, collect evidence, and automatically prepare detailed assessments.
- The other way is one where AI becomes a part of the payment environment itself. For example, it can be a customer support agent that retrieves transaction details or a retail AI system connected to the payment infrastructure.
Both of these use cases raise different security and scope questions. The scope that falls under compliance audits depends on the AI components in place and the overall payment system architecture, not just the model or models you use.
Kyrylo points out:
Interfaces, APIs, data retrieval methods and sources, connected tools, credentials, logs, and third-party integrations affect the ways data moves around and what individual parts of the system are allowed to access.
The most notable risk factors are:
Account data exposure
May happen when a support agent obtains transaction records containing full card numbers, or a prompt sends Primary Account Numbers (PANs) to an external model provider.
Unrestricted connectivity
Can occur when an AI assistant connects to a payment database or cloud storage that contains Cardholder Data Environment (CDE) components, even if it’s not supposed to directly handle card data.
Security-related modifications
Possible threat if an AI agent is authorized to change firewall rules, modify scripts on the payment page, or manage access to CDE protection perimeter.
According to Kyrylo:
An LLM model doesn't even need to save or process cardholder data for the AI system around it to fall within PCI DSS scope. It’s just a cog, although a big one, within a larger mechanism.
In the end, it’s a combination of flows within the system, data access rights, and capabilities of each element that collectively define the compliance scope.
What is PCI SSC guidance for payment AI?
With just a one-letter difference between the two, PCI DSS and PCI SSC are easy to confuse.
PCI DSS sets the security requirements, while the PCI Security Standards Council (PCI SSC) publishes guidance on applying them to AI systems. The guidance addresses AI-specific risks and recommended safeguards, but does not introduce a separate AI certification2. In summary, their guidance revolves around the following principles.
Never should AI systems expose unprotected PAN (personal account data) or secrets, be granted access that is excessive for their assigned tasks, be singularly responsible for security-related decisions, or publish generated code to production environments without human supervision and approval.
AI systems should handle all account data exclusively through protected processes, use their own assigned credentials, and keep complete logs that explicitly associate actions with identifiable users or services. In addition, PCI SSC guidelines recommend that all such systems be regularly validated throughout their lifecycle, offer a way to disable them, be equipped with effective controls against malicious inputs and unsafe outputs, and require human review of sensitive actions.
Certain actions are allowed if controls and limitations are in place: using tokens or single-serving PANs, asking for human approval of AI recommendations, blocking actions safely during an ongoing cyberattack, creating log summaries, or generating policies and code for subsequent human review.
Keep AI away from card data
Bring AI into payment operations without exposing sensitive data or expanding PCI DSS scope.
Transitioning from manual checks to AI-driven compliance
If your payments layer is mostly static and stable, manual checks can be a viable option. You set up an internal schedule, collect evidence, and log it in a spreadsheet or any other format of your choice, then use this data for generating compliance reports.
As your systems evolve and new vendor integrations are added, your team will start spending significantly more time gathering data, manually checking configurations, and updating reports. With so much to keep an eye on, overlooked synchronization gaps might become a serious risk.
AI can automate some of this work by monitoring your payment infrastructure and juxtaposing evidence with relevant PCI DSS requirements.
As Kyrylo puts it:
The goal of AI in this case is to reduce the amount of manual labor and detect issues early on, not to completely hand compliance decisions over to an LLM. AI is a great tool for spotting potential gaps and their summarization, but it’s real people who must validate the evidence and take action.
Multi-agent architecture: How to assign the right work to the right agent
With several distinct lines of compliance-related work, a multi-agent setup with clearly defined roles and areas of responsibility effectively checks every box. Here is what could happen if the DevOps team changed the configuration of a cloud service that supports payment operations.
Requirements retrieval
A retrieval-augmented generation (RAG) component would embed the latest relevant PCI DSS requirements and the company's internal security guides into a vector database, giving other agents a single shared source of truth to rely on.
Inspection
An infrastructure scanner would check the changed service, collect updated configuration details, and highlight settings that could be in conflict with the requirements.
Evidence check
A gap-analysis agent would map the results of the scanner's work to previously extracted requirements, identify missing evidence, and flag potential non-compliant pieces for review.
Pre-assessment simulation
A dedicated agent simulating a QSA auditor would examine the findings obtained so far and available documentation, find unanswered questions, and suggest what a real assessor could request next.
Summarization
The system would then assemble the full body of evidence, associate each finding with the relevant compliance requirement, and submit the summary along with a list of unresolved issues to the responsible security or compliance specialist.
In such setups, agents constantly exchange their findings and pieces of evidence without relying on a single decision-maker and waiting for feedback or approval. This makes it possible for scanning, evidence collection, and gap detection to run continuously and autonomously within preapproved boundaries. However, any changes to configurations or security controls require validation and authorization by a qualified human.
Kyrylo explains:
The key here is to explicitly separate agents’ responsibilities and narrow their authority to match their function only. An agent created to detect potential configuration issues should not have a default permission to modify the production infrastructure or declare a control compliant. This makes it much easier to audit the entire process and substantially lowers the risk of random AI hallucinations turning into dangerous security incidents.
Four steps toward continuous PCI DSS compliance
With semi-autonomous AI agents, PCI DSS compliance can be turned from a periodic, pre-planned exercise into an ongoing process where even slight deviations from guidelines can be caught and handled early on. A practical workflow has just four steps.
- The process starts with identifying cardholder data, connected systems, and components within the PCI DSS scope.
- AI then helps compare existing controls against applicable requirements and flag potential gaps.
- Technical evidence is collected continuously, with sensitive data detected and masked before reaching storage, logs, or AI services.
- Finally, security teams review findings, address issues, and track changes that may require reassessment.
Kyrylo adds:
While AI models can support each step with appropriate pretraining, they cannot fully replace properly designed and implemented discovery mechanisms or human oversight.
Applying the approach to real payment architectures
The theoretical principles of AI-driven PCI DSS compliance become easier to grasp when they are applied to real fintech products and business cases. The rule of thumb for any payment software development project is simple: reduce PCI DSS scope as much as possible, maintain security boundaries at all times, and implement automation carefully without exposing sensitive cardholder data.
To illustrate how these principles translate into engineering practice, here are two projects we believe are particularly relevant to the intersection of AI and PCI DSS compliance. The first one is about building a secure, AI-enabled payment gateway architecture from the ground up. The second shows how modern AI can help reverse-engineer and rebuild a complex legacy system while substantially reducing PCI DSS scope.
Project 1: Isolating card data in a token vault
When building a proprietary payment gateway for a US-based payment processing company, our team chose a compliance-by-design approach with security and scope reduction being the top architectural priorities right from the start.
The initial focus was on the creation of a fully isolated token vault for storing raw cardholder data. This separation opened a way for implementing an AI-powered reconciliation system that automatically matched transactions with bank and processor statements without giving the AI system access to sensitive card data.
Kyrylo recalls:
The AI workflow worked exclusively with tokens and cleaned-up transaction data. The result was a payment architecture in which AI could optimize and accelerate business-critical processes without inflating the PCI DSS scope.
Project 2: Mapping card data flows in a legacy monolith
Legacy modernization projects are challenging for a different reason: cardholder data may be hidden deep inside old databases and baked into the business logic. One such project that we worked on contained over 2000 T-SQL stored procedures that made up a monolith where PANs and other sensitive fields were extremely intertwined.
Rather than relying solely on manual code analysis, Oxagile's team used AI models to accelerate reverse engineering and PCI DSS scoping. Having analyzed the vast array of stored procedures and associated metadata, the models managed to reliably identify previously unseen paths through which cardholder data could flow, created detailed process maps, and established the boundaries of the cardholder data environment.
Kyrylo shares:
This approach made it possible to isolate cardholder data in a secure vault without breaking the integrity of business operations. The AI tools were allowed to analyze code structure and metadata with no access to raw cardholder records, and the team could explore the legacy architecture without exposing sensitive data to the models.
Keeping AI systems outside of sensitive payment data flows
The basic engineering principle here is that AI compliance tools, at a bare minimum, must not create new security risks. So how can companies use AI to improve payment operations and automate compliance without exposing cardholder data or expanding PCI DSS scope?
Kyrylo replies:
Architecture is the answer: minimal data exposure, enforced access controls, and security boundaries established independently of the AI model.
When AI becomes part of PCI DSS scope
PCI DSS v4.0.1 doesn't mention AI at all. From the standard’s perspective, AI is just as good or bad as any other technology out there. Its scope simply follows data and connectivity, so if a system stores, processes, or transmits cardholder data, or is connected to or can affect the security of the cardholder data environment, it must be evaluated against applicable PCI DSS requirements.
As we saw in the examples above, this could be a case of an AI-based tool scanning legacy databases, a reconciliation engine processing settlement files, or a fraud detection model analyzing real-time authorization streams, although every case would have different scoping considerations.
Keep raw card data out of AI workflows
Let’s use our AI-powered reconciliation engine as an example again. Card data is captured by a protected payment component and then gets forwarded to an isolated tokenization service that replaces PANs with tokens. This data preparation layer gets rid of unnecessary fields and rectifies transaction records before passing them to the AI model. As a result, the model matches transactions against bank/processor statements using only the information it needs for the task.
The same safeguards should extend to data retrieval sources, tool calls, application logs, and downstream integrations. Each can expose sensitive data without proper filtering and access controls.
This protection has to be explicit and implemented programmatically. Simply writing a detailed prompt and asking a model to ignore sensitive data will not prevent it from receiving that data, following malicious instructions, or inadvertently sharing information through connected tools.
Kyrylo notes:
Surprisingly, even card data tokenization does not automatically remove systems from PCI DSS scope. Each element of the tokenization mechanism should be reviewed, including re-identification methods and system connectivity.
Securing LLMs and multi-agent systems
The use of LLMs always comes with risks like prompt injection, sensitive data exposure through RAG and logs, excessively broad agent permissions, and unchecked outputs. These risks can be mitigated by:
- Isolating credentials
- Granting each agent access to just the tools it needs
- Validating proposed actions manually or programmatically
- Keeping detailed audit logs
- Implementing an emergency kill switch
These measures are fully in line with the PCI Security Standards Council's AI guidance, which provides additional recommendations pertaining to PCI compliance for retail AI systems and addresses AI usage scenarios that may be acceptable with properly implemented controls in place.
In multi-agent architectures, it’s important to separate analysis from execution. If an agent identifies a compliance gap, it should not automatically be able to modify production infrastructure. Such a decision should require human intervention.
Kyrylo warns:
An LLM should never be treated as part of a trusted security space. You cannot rely on an elaborate prompt or other instruction to protect real card numbers or prevent unauthorized actions. Real protection comes from the architecture around it: strictly controlled data access, isolated credentials, restricted list of tools, and validation of everything the model attempts to do.
What assessors need to see
When assessors show up to confirm PCI DSS AI compliance for merchants or payment service providers, the thing they are interested in the most is solid, verifiable evidence, not just plausible conclusions made by AI or the team. They look for:
- Clear control ownership
- Detailed access logs
- Reliable validation results
- Documented decisions
AI can help with some of that, like putting together documents, summaries, reports, and, of course, detecting potential gaps3. Your team may also benefit from running an AI-based QSA simulator every now and then to be better prepared for actual assessments and their difficult questions.
A real QSA, nevertheless, will be looking at the whole picture with more scrutiny than you ever did, since they will be drawing final conclusions and signing off on the assessment results. Once the assessment is over, its results must be stored securely to prevent unauthorized access or leakage to public LLMs.
Concluding thoughts on AI PCI compliance
The use of modern AI models can dramatically change your PCI DSS compliance routine. If you’ve been doing what most businesses still do (that is, throwing everyone and everything on collecting relevant data and evidence once a year to pass the audit), you’ll be surprised how much easier your life can be with continuous monitoring of controls, gaps detection, and preparing evidence well in advance.
At the same time, automation does not take the accountability factor away. Your goal is not to build a swarm of AI agents that'll unanimously call an environment compliant, but to create and streamline a payment architecture where security is continuously verified and human experts remain responsible for the decisions that matter for your business.
Kyrylo specifies:
The ultimate goal of any organization isn’t compliance in full self-driving mode. It’s more along the lines of having a crystal-clear, 360-degree view of your surroundings at any given moment. Being informed and knowing where to look for information when an auditor asks for it is a fast lane towards passing audits with flying colors.
Check every box in advance
Oxagile helps automate PCI DSS checks, protect cardholder data, and keep compliance evidence up to date.
Sources:
- — PCI Security Standards Council
Eight Steps to Take Toward PCI DSS v4.0
- — PCI Security Standards Council
Security Considerations for AI Systems
- — PCI Security Standards Council
Integrating Artificial Intelligence into PCI Assessments
FAQ
Does PCI DSS apply if the model never stores the card number?
Yes. An AI system may fall within PCI DSS scope even if the model never stores a Primary Account Number (PAN). Connectivity to the cardholder data environment and the ability to affect its security also matter. Oxagile evaluates data flows, integrations, access permissions, and security controls when designing AI-enabled payment architectures.
Can AI replace a PCI assessment?
AI can support PCI DSS assessments by collecting evidence, reviewing configurations, identifying potential compliance gaps, and preparing documentation. Yet, it cannot independently validate compliance or replace the responsible human assessor. PCI SSC guidance explicitly requires qualified human oversight of AI-assisted assessments.
Can we do PCI compliance ourselves?
Eligible merchants may validate PCI DSS compliance through a Self-Assessment Questionnaire (SAQ), depending on their payment environment and applicable card-brand or acquirer requirements. Others must undergo a formal assessment by a Qualified Security Assessor (QSA). Oxagile can support the technical preparation, including PCI scope reduction, security architecture, automated control monitoring, and evidence collection.
Is PCI compliance a law?
No, PCI DSS is an industry security standard, not a law. Compliance obligations generally arise through payment card network rules and contractual agreements with acquiring banks or payment processors. However, some jurisdictions have laws that reference PCI DSS or impose related payment-data security requirements. Legal obligations vary by location.