El PCI SSC recuerda cómo proteger la IA en el entorno de pagos

El 7 de octubre de 2026, el PCI SSC publicó una declaración sobre la seguridad de la IA en el entorno de pagos. El documento al que remite se presentó ya el 15 de septiembre. El propio Consejo señala que se trata de recomendaciones y que, en caso de discrepancia, prevalecen los estándares oficiales de PCI. El comunicado de octubre no introduce un estándar de IA obligatorio propio.

El riesgo depende de la acción que se permite al sistema

Para un equipo de pagos, la diferencia se ve bien con dos asistentes. Uno explica al cliente el estado de su pedido. El otro puede modificar la configuración de aceptación de pagos o tramitar reembolsos. Que ambos usen el mismo modelo no hace que sus riesgos sean iguales: importan los datos accesibles, los permisos y las consecuencias de una acción errónea.

Por eso, la parte sustancial del debate sobre la IA está en el diseño de la integración. ¿Qué registro entrará en la consulta? ¿Quién verá la respuesta? ¿Puede el resultado del modelo modificar directamente una operación financiera? Estas preguntas describen un recorrido de datos y acciones que se puede verificar, a diferencia de la promesa genérica de una «IA segura».

Una prueba reveladora es el correo de un comprador que pide un reembolso e incluye instrucciones adicionales sin relación con su pedido. El sistema debe atender la solicitud legítima dentro de sus permisos, y no tratar todo el texto externo como una orden del propietario del servicio. Es un ejemplo editorial de prueba de integración, no una regla tomada literalmente del nuevo documento.

El PCI SSC indica que la IA debe tenerse en cuenta al determinar los requisitos aplicables, igual que cualquier otra tecnología. En la práctica, la aparición de un modelo no saca el proceso del perímetro de control de datos y de accesos. El alcance concreto de la evaluación se define según el entorno real y con especialistas cualificados.

El resultado principal de este trabajo es poder reconstruir lo ocurrido: qué datos recibió el sistema, qué acción propuso, quién la autorizó y cómo detenerla en caso de error. La fecha de la declaración de octubre no es un nuevo plazo de certificación. La noticia sirve como recordatorio de que la autonomía de una herramienta de pagos exige una descripción igual de concreta de las responsabilidades.

Qué debe revisar el equipo de pagos

Una forma práctica de empezar es hacer un inventario de todos los lugares donde los modelos ya trabajan cerca de los datos de pago: soporte, antifraude, gestión de disputas y asistentes internos para desarrolladores y analistas. Estas herramientas suelen aparecer en los equipos sin una aprobación específica, y precisamente son las primeras que hay que identificar.

• Qué herramientas de IA reciben datos de titulares de tarjetas o tienen acceso a sistemas donde se almacenan.
• Qué acciones puede ejecutar el modelo por sí solo y cuáles requieren confirmación humana.
• Cómo se separan las instrucciones del propietario del servicio del texto que llega del cliente o de fuentes externas.
• Si se registran las consultas, las respuestas y las acciones ejecutadas, y quién revisa esos registros.
• Cómo se desactiva la función ante un fallo: si existe un modo manual para reembolsos y soporte.
• Qué dicen los contratos con los proveedores de modelos sobre el almacenamiento, el tratamiento y la reutilización de datos.

Riesgos y limitaciones

Las recomendaciones no sustituyen la evaluación de cumplimiento y no pueden usarse como una lista de verificación lista para auditoría. Un riesgo aparte son los servicios de modelos externos: si una consulta con datos de pago se envía a un proveedor, cambian los límites del entorno y hay que revisar el contrato y el recorrido de los datos. Conviene tratar estas cuestiones con un QSA o con el área de cumplimiento interna antes del lanzamiento, no después del primer incidente.

Fuentes: PCI SSC statement; PCI SSC information supplement introduction