Skip to main content

PCI DSS and AI: Protecting Payment Card Data in LLM Workflows

PCI DSS and AI: Protecting Payment Card Data in LLM Workflows

Payment-card data reaches AI systems through the least glamorous paths: dispute summaries, support chats, chargeback notes, pasted receipts, and fraud-review workflows. The engineering mistake is to think card data only exists inside the checkout system. In reality, the risk often appears later when someone asks a model to summarize, classify, or draft a response using text that still contains a PAN, CVV, expiration date, or other card-adjacent detail. Keeptrusts helps contain that risk at the gateway so raw payment-card data is redacted or blocked before the model sees it.

Use this page when​

  • Your AI workflow touches support, disputes, fraud operations, or finance-adjacent text that may contain payment-card data.
  • You need to apply PCI-aware controls without sending every prompt through manual review.
  • You want evidence that shows whether card data was blocked, redacted, or routed into a compliant provider lane.

Primary audience​

  • Primary: Technical Engineers
  • Secondary: Technical Leaders, payment-security reviewers

The problem​

PCI programs often assume tokenization at the application layer is enough. It is not enough when people still paste screenshots, transcripts, or copied notes into AI tools. The most common failure is not an attacker breaching the gateway. It is an employee or workflow forwarding raw card data to a model that never needed it in the first place.

Card data also travels with extra context. A chargeback prompt might contain a PAN, a customer email address, a shipping address, and a copied fraud case note. That means payment-card protection cannot rely on one detector alone. It needs to catch the obvious card artifacts while also guarding against the surrounding sensitive context.

There is one more detail that matters for accurate design: PII Detector in pci_mode detects PAN values, CVV or CVC values, and expiration dates. The current implementation does not detect cardholder names. Teams that ignore that limitation often think they are done when they are not.

The solution​

The practical pattern is to combine built-in PCI detection with custom DLP rules and strict provider routing.

Use PII Detector with pci_mode: true so obvious payment-card artifacts are detected and redacted or blocked before the provider call. That is your base layer.

Then add DLP Filter for the things PCI mode does not know about: track-data patterns, internal dispute packet labels, proprietary fraud signals, and local system identifiers. This is also where you block phrases that indicate raw card exports or unsafe operational behavior.

Finally, add Data Routing Policy so any surviving request can only route to a target that declares zero retention, no training, in-memory handling, tokenized-input support, and no internet egress. In PCI-sensitive AI flows, routing discipline matters as much as redaction because a redacted request still contains business context that should not spill into a weak provider path.

Implementation​

This is a strong starting point for payment-support or fraud-review prompts that need to stay useful after sensitive card data is stripped out:

pack:
  name: pci-ai-governance
  version: "1.0.0"
  enabled: true

providers:
  targets:
    - id: pci-zdr
      provider: openai
      model: gpt-5.4-mini-mini
      secret_key_ref:
        env: OPENAI_API_KEY
      data_policy:
        zero_data_retention: true
        training_opt_out: true
        retention_days: 0
        in_memory_only: true
        sanitized: true
        accepts_tokenized_input: true
        allow_internet_egress: false
        local_only_processing: true

policies:
  chain:
    - pii-detector
    - dlp-filter
    - data-routing-policy
    - audit-logger

policy:
  pii-detector:
    action: redact
    healthcare_mode: false
    pci_mode: true
    redaction:
      marker_format: label
      include_metadata: true
      custom_markers:
        generic_id: "[REDACTED-CARD-ADJACENT-ID]"

  dlp-filter:
    detect_patterns:
      - ';[0-9]{13,19}=[0-9]{4,}'
      - 'AUTH-[0-9A-Z]{6,12}'
      - 'ORDER-[0-9]{10,14}'
    blocked_terms:
      - full card dump
      - cvv spreadsheet
      - track 2 data
    action: block
    fuzzy_matching: true
    max_distance: 1
    sensitivity_level: high

  data-routing-policy:
    require_zero_data_retention: true
    require_no_training: true
    max_retention_days: 0
    require_in_memory_only: true
    sanitize_before_provider: true
    tokenize_sensitive_fields: true
    allow_internet_egress: false
    local_only_processing: true
    on_no_compliant_provider: block
    log_provider_selection: true

  audit-logger: {}

This configuration gives you a useful split. pii-detector removes the common PCI artifacts that can often be safely masked. dlp-filter hard-blocks higher-risk payment exports and organization-specific patterns. data-routing-policy makes sure redacted traffic still goes only to a provider lane that satisfies your declared handling rules.

Operationally, validate with kt events so you can distinguish between redacted and blocked flows. That matters during rollout because support teams often want summarization to continue after masking, while security teams may require hard blocks for obvious raw exports. Keeptrusts lets you make that distinction on purpose rather than by accident.

Results and impact​

The first result is straightforward: fewer raw PANs, CVVs, and expiration dates reach the upstream model. That reduces unnecessary cardholder-data exposure without forcing every business workflow into manual review.

The second result is better control over edge cases. Teams quickly learn where pci_mode is strong, where custom DLP rules are still required, and which provider paths are actually eligible for payment-sensitive traffic.

The third result is better evidence for payment-security reviews. Instead of arguing from assumptions, you can export governed events, review blocked versus redacted verdicts, and show the provider-selection constraints that protected the lane.

Key takeaways​

  • PCI controls in AI need both content minimization and provider-routing discipline.
  • PII Detector with pci_mode catches PAN, CVV, and expiration data, but it does not detect cardholder names.
  • DLP Filter should carry your track-data, dispute-packet, and organization-specific payment patterns.
  • Data Routing Policy turns zero-retention and no-training requirements into runtime enforcement.
  • Evidence from kt events and kt export-jobs makes PCI review much easier than relying on application logs alone.

Next steps​