El 15 de septiembre el Consejo PCI publicó su primera guía sobre IA en entornos de pago. Lo primero que conviene saber está impreso al pie de sus 26 páginas: lo que dice no sustituye ni deroga ningún requisito de ninguna norma PCI.
Desde entonces circulan titulares del tipo «PCI ya exige aprobación humana para los agentes de IA». No es así. Es un suplemento informativo, y un suplemento informativo es orientación. Lo que sí tiene efecto inmediato es otra cosa, mucho menos comentada. Es una frase sobre alcance que puede meterte sistemas nuevos dentro del entorno de datos de tarjeta, sin que hayas tocado tu infraestructura.
- Es orientación, no requisitos. Cuando la guía y la norma no coincidan, manda la norma.
- No añade ni un requisito nuevo. Dice dónde cae la IA dentro de los que ya cumples.
- Si un sistema de IA accede a datos de cuenta, o tiene conectividad sin restringir con sistemas que sí acceden, es parte del CDE por definición.
- Pasarle datos de tarjeta a una IA no está prohibido. Lo que hace es meterla en alcance.
- No cubre los pagos ejecutados por agentes de IA. Ese documento todavía no existe.
Qué es la guía de IA en entornos de pago, y qué no es
Es un suplemento informativo en versión 1.0, elaborado por el Consejo junto al Global Executive Assessor Roundtable y al Consejo Asesor. Cubre cuatro bloques: cómo desplegar sistemas de IA, cómo defenderse de los ataques que usan IA, cómo encajan en las normas PCI y cinco ejemplos de uso.
Y hay tres cosas que no es, que importan tanto como lo anterior.
- No es una norma. La propia guía repite que no sustituye, amplía ni anula ningún requisito existente.
- No trata el uso de IA en las evaluaciones. Eso está en otro documento distinto, «Integrating Artificial Intelligence in PCI Assessments».
- No trata los pagos hechos por agentes. El comercio agéntico queda explícitamente fuera. Solo habla de proteger los datos que se le dan a una IA y de proteger el entorno frente a atacantes que usan IA.
La frase que sí cambia tu alcance
Es esta: cuando se usa IA, debe considerarse igual que cualquier otra tecnología a la hora de determinar qué requisitos aplican. Suena inofensiva y no lo es.
El Consejo lo lleva al requisito 12.5.2, que es donde confirmas tu alcance al menos una vez al año. Cualquier IA en entornos de pago se revisa ahí como un componente más. Y la consecuencia está escrita sin matices. Un sistema de IA que accede a datos de cuenta forma parte del entorno de datos de titulares de tarjeta por definición. También si está instanciado con conectividad sin restringir hacia sistemas que sí acceden.
Pasar datos de tarjeta a una IA no está prohibido en ninguna parte. Lo que ocurre es que esa IA entra en alcance, y con ella los sistemas donde se ejecuta.
El documento lo aterriza con un ejemplo que vale la pena leer dos veces. Una IA que solo ve datos cifrados o tokenizados puede quedar fuera de alcance. Pero únicamente si está aislada del HSM o del KMS, de los sistemas que descifran y de las cuentas que pueden usarlos. En ese caso, el aislamiento sí entra en alcance, porque hay que demostrar que aísla de verdad. Si no está aislada de forma explícita, si el aislamiento es insuficiente, o si puede llegar al sistema de control de accesos, la IA está dentro.
Añade un detalle operativo que se escapa en casi todas las lecturas: esos controles de aislamiento entran en el alcance de tus pruebas de penetración y de segmentación. No basta con haberlos configurado, hay que haberlos probado.
El trío letal, que es el resumen útil
La guía recoge un concepto que se entiende en diez segundos y sirve para decidir rápido. Un sistema de IA no debería tener a la vez estas tres cosas: acceso a datos sensibles, exposición a contenido que no controlas, y comunicación con el exterior.
La lógica es sencilla. Cuanto más sensible sea el dato al que llega, más lejos tiene que estar del contenido no fiable y del exterior. Si una tarea necesita las tres patas, la respuesta no es vigilarla mejor: es partirla entre varios agentes, cada uno con lo mínimo para su parte. Y entonces aparecen dos riesgos nuevos, que el documento nombra. Uno, que un agente «contagie» a otro con instrucciones malintencionadas escondidas en los datos. Otro, que varios agentes acaben colaborando hacia un resultado que nadie quería.
El propio Consejo avisa de que el trío letal es, como mucho, una herramienta rápida. No sustituye a un análisis de riesgo ni a un modelado de amenazas en condiciones.
La MFA que una IA no puede cumplir
Este punto es el más concreto de toda la guía. Afecta a cualquiera que tenga encima el requisito 8.4.2, la autenticación multifactor para todo acceso al entorno de datos.
Un sistema de IA no puede hacer MFA. No puede tener un factor de posesión ni uno de inherencia: no posee nada y no es nadie. La salida que propone el Consejo es sustituirlo por credenciales ligadas al dispositivo, y a ser posible criptográficas: certificados específicos por dispositivo con mTLS, o credenciales resistentes al phishing.
Con tres condiciones que conviene anotar. La credencial tiene que ser atribuible a esa IA y solo a esa IA, nunca compartida ni reutilizable. Tiene que estar acotada en el tiempo. Y no se puede usar una IA para colarse por un sitio donde a una persona se le exigiría MFA.
Lo que una IA nunca debe hacer
La guía consolida una lista mínima de cosas que un sistema de IA no debería poder hacer nunca. No es exhaustiva, y el documento pide que cada empresa la amplíe.
- 1 Ver secretos de alto impacto en claro, como claves criptográficas, componentes de clave o contraseñas.
- 2 Generar aleatoriedad o secretos. Son malas generando entropía. Si hace falta, se le da acceso a una función conocida y validada que lo haga por ella.
- 3 Tomar decisiones de las que ninguna persona pueda responder.
- 4 Compartir credenciales o actuar de forma que sus acciones no sean atribuibles de manera única.
- 5 Llegar a sistemas que no necesita para la tarea que tiene asignada.
Y una regla que resume todas las demás: una IA no recuerda, almacena. Si algo no puede estar guardado en claro, no se le entrega en claro.
Si la IA la pone un tercero
Aquí la guía es tajante. Si cualquier parte del sistema de IA la aporta o la aloja alguien de fuera, y tiene acceso a datos sensibles, ese tercero es un proveedor de servicios. Le aplican los requisitos 12.8.x en pleno.
Incluye un caso que mucha gente no ha contado como IA: la que viene integrada dentro de otros productos. Lectores de documentos, herramientas de creación de contenido y, sobre todo, widgets de chat en la propia página de pago. Esos widgets, además, hay que autorizarlos, inventariarlos y vigilar que nadie los manipule, exactamente igual que cualquier otro script de la página de pago. Son los requisitos 6.4.3 y 11.6.1, que ya conoces si leíste qué cambió en PCI DSS 4.0.
En la práctica eso significa cinco cosas. Un contrato escrito que reparta la responsabilidad sobre los datos. Una prohibición explícita de usar tu información para entrenar modelos. Visibilidad de los subencargados y condiciones de notificación de brechas. Y evidencia de diligencia revisada con una periodicidad fija.
Qué hacer esta semana
Cinco cosas, todas pequeñas, y todas aplicables a cualquier IA en entornos de pago que ya tengas funcionando.
- 1 Inventariar. Los sistemas de IA van al inventario de componentes del 12.5.1 y a los diagramas de flujo de datos del 1.2.4. La regla del Consejo es clara: a ningún sistema de IA se le da acceso a datos que la empresa no haya clasificado y mapeado antes.
- 2 Contar lo que la IA crea. Registros de instrucciones y respuestas, transcripciones, cachés, contexto de sesión, memoria temporal, resultados de herramientas y estado de orquestación. Todos son almacenes de datos, y los de tarjeta se enmascaran antes de escribirlos.
- 3 Ponerle dueño y revisión. Cada sistema de IA con una persona concreta que aprueba su despliegue, sus tareas y los datos a los que llega. Revisión al menos trimestral, o con la cadencia que justifique un análisis de riesgo dirigido.
- 4 Buscar la IA en la sombra. Política de uso aceptable, lista de herramientas autorizadas y algún método real de detectar las que no lo están. No basta con confiar en que se cumpla la política.
- 5 Meterla en el plan de respuesta. El requisito 12.10.x pide un plan probado. Añade escenarios propios de IA, como una inyección de instrucciones que funcione o una acción autónoma fuera de su ámbito, aunque todavía no te haya pasado.
Dónde encajamos
Casi todo lo anterior no es un problema de comprar nada. Es alcance, inventario y justificación escrita, que es justo donde se cae la mayoría de las evaluaciones. Ahí entra la consultoría de PCI DSS dentro de la práctica de PCI DSS, y cuando toca la evaluación formal, la auditoría QSA.
De los requisitos citados, los de registro y supervisión se sostienen sobre un SIEM gestionado. Los de credenciales y accesos de los agentes, sobre el control de accesos críticos. Defenderse de atacantes que ya usan IA es la mitad menos comentada del documento. Se traduce en escaneo continuo y triaje rápido, que es gestión de vulnerabilidades. Habla con el equipo.
Fuentes
- PCI Security Standards Council, anuncio de publicación de «Security Considerations for AI Systems», 15 de septiembre de 2026.
- PCI Security Standards Council, «Security Considerations for AI Systems», suplemento informativo versión 1.0, septiembre de 2026. De ahí salen el alcance, el trío letal, el requisito 8.4.2 y los ejemplos de uso.
- PCI Security Standards Council, biblioteca de documentos, donde está también «Integrating Artificial Intelligence in PCI Assessments».
- Referencias que cita la propia guía: ISO/IEC 42001 para el sistema de gestión de IA y el marco de gestión de riesgos de IA del NIST.
