Preguntas de seguridad empresarial para proveedores de plataformas de negociación

Los compradores que evalúan la seguridad de una plataforma de negociación deben pedir a los proveedores que demuestren —y no se limiten a afirmar— cómo aíslan los datos de los clientes, controlan la retención y eliminación, aplican el cifrado, restringen los permisos y generan registros de auditoría fiables. Estos controles deben abarcar toda la arquitectura de la plataforma de negociación, incluidos los prompts, los archivos adjuntos, los embeddings, las copias de seguridad, las herramientas de soporte, las integraciones y los subencargados del tratamiento.

En materia de seguridad de la negociación con IA y privacidad de datos en plataformas de negociación, un cuestionario es solo el comienzo. Los equipos de compras empresariales necesitan diagramas de arquitectura, resultados de pruebas, demostraciones de configuración, registros de ejemplo, compromisos contractuales y aprobación humana responsable del riesgo residual. Una certificación puede respaldar la revisión, pero no sustituye la evidencia específica del producto.

Respuesta breve

Pregunte cómo separa el proveedor a cada cliente, qué datos almacena y elimina, dónde se aplica el cifrado, quién puede realizar acciones sensibles y qué eventos pueden auditar los clientes. Solicite diagramas de arquitectura, resultados de pruebas, calendarios de retención, detalles de gestión de claves, matrices de permisos y registros de ejemplo. Después, convierta las respuestas aceptadas en obligaciones contractuales, con la aprobación de las excepciones por parte de los responsables de seguridad, privacidad, asuntos legales, compras y negocio.

Cinco controles, cinco requisitos de evidencia

Use este resumen para estructurar la primera reunión con el proveedor.

El Marco de Ciberseguridad 2.0 del NIST identifica la autorización de acceso, la protección de datos y la generación de registros como resultados de ciberseguridad. Es una referencia útil, no una prueba de que un proveedor concreto haya implementado esos resultados de manera eficaz.

1. Ponga a prueba el aislamiento en toda la arquitectura

El aislamiento entre clientes consiste en impedir que un cliente o una carga de trabajo acceda a los datos de otro o los afecte. Un proveedor puede afirmar que cada registro de la base de datos incluye un identificador de cliente, pero esa respuesta no contempla los índices de búsqueda, las cachés, los análisis, el almacenamiento de archivos, las integraciones ni los servicios de IA.

Pida al proveedor que identifique todos los componentes en los que pueden coexistir datos de clientes:

• Servicios de aplicaciones y API
• Bases de datos, réplicas y almacenes de datos
• Almacenamiento de objetos y archivos adjuntos
• Cachés y colas de mensajes
• Índices de búsqueda y recuperación
• Sistemas de análisis y diagnóstico
• Prompts, resultados, embeddings y datos de evaluación
• Entornos de desarrollo, prueba, demostración y soporte
• Proveedores de modelos y otros subencargados del tratamiento

Después, pregunte cómo se verifica la identidad del cliente para cada solicitud de objeto y llamada a la API. ¿El aislamiento se aplica mediante la infraestructura, las cuentas, los esquemas, las políticas de bases de datos o el código de la aplicación? ¿Dónde podría un error de programación cruzar un límite?

La publicación NIST SP 800-53, versión 5.2.0 incluye controles relacionados con el acceso, los recursos compartidos y la protección de la información almacenada. Su publicación complementaria de evaluación, NIST SP 800-53A, respalda un principio de compra importante: solicite evidencia de que un control está implementado y funciona, no solo una política que diga que debería existir.

Preguntas sobre evidencia de aislamiento

1. ¿El alcance de las pruebas de penetración incluye explícitamente el acceso entre clientes?
2. ¿Se probaron las rutas de API, búsqueda, exportación, caché y almacenamiento de archivos?
3. ¿Se copian datos de producción a entornos que no son de producción?
4. ¿Cómo obtiene el personal del proveedor acceso temporal a producción?
5. ¿Se aprueba, limita en el tiempo, registra y revisa el acceso?
6. ¿Los prompts de IA, los índices de recuperación, los resultados y los embeddings están aislados por cliente?
7. ¿Ha sufrido el proveedor una exposición confirmada o presunta de datos de otro cliente y cómo la gestionó?

Una carta genérica sobre pruebas de penetración no es suficiente si el producto adquirido, la región de implementación, las funciones de IA o los límites entre clientes quedaron fuera del alcance de las pruebas.

2. Defina la retención antes de negociar la eliminación

La privacidad de datos en plataformas de negociación depende de algo más que una promesa de «eliminar los datos del cliente al finalizar el contrato». Una negociación de compras puede generar ofertas, archivos adjuntos de proveedores, notas internas, historiales de aprobación, prompts, resultados de modelos y metadatos comercialmente sensibles. También puede haber copias en registros, réplicas, tickets de soporte, copias de seguridad y sistemas de subencargados del tratamiento.

Elabore una matriz de retención antes de aceptar las condiciones propuestas por el proveedor:

No copie de una lista de verificación un período de retención universal. Los períodos adecuados dependen de las necesidades de investigación, los plazos de controversia, las políticas de la empresa, las obligaciones legales, la sensibilidad de los datos y las funciones de las partes.

Cuando se apliquen las normas del RGPD sobre encargados del tratamiento, los contratos generalmente deben abordar la devolución o eliminación de los datos personales y la asistencia para auditorías. El reglamento también establece el principio de limitación del plazo de conservación. Consulte el texto oficial del RGPD. El asesor jurídico debe determinar si esas normas se aplican a una implementación concreta y de qué manera.

Preguntas contractuales sobre retención

• ¿Puede el comprador configurar la retención por categoría de datos?
• ¿Qué elimina realmente una acción de eliminación visible para el usuario?
• ¿Con qué rapidez se eliminan las copias activas, las cachés y las réplicas?
• ¿Cuándo vencen las copias de seguridad inmutables?
• ¿La eliminación incluye los índices derivados y los embeddings?
• ¿Qué datos pueden conservarse debido a una retención legal?
• ¿El proveedor ayudará a exportar los datos antes de la finalización del contrato?
• ¿Quién firma la certificación de eliminación?
• ¿Se imponen requisitos equivalentes a los subencargados del tratamiento?

La guía de seguridad para proveedores de la FTC recomienda especificar contractualmente las expectativas sobre el uso, la retención, el intercambio y la eliminación de datos por parte de los proveedores, y verificar su cumplimiento en lugar de confiar en garantías.

3. Mire más allá de un eslogan sobre cifrado

«Cifrado con AES-256» no responde dónde se aplica el cifrado, quién controla las claves ni qué ocurre cuando la aplicación utiliza datos en texto sin formato. El cifrado no puede impedir el uso indebido por parte de una aplicación o un administrador autorizados, ni de una cuenta comprometida.

Pida al proveedor que explique cada estado de los datos:

• En tránsito: sesiones del navegador, API, integraciones, conexiones con proveedores de modelos, canales de soporte y exportaciones de datos
• En reposo: bases de datos, archivos adjuntos, registros, réplicas, copias de seguridad, índices y embeddings
• En uso: búsquedas, análisis, inferencia de modelos, procesamiento de documentos y generación de recomendaciones

La gestión de claves debe abarcar su generación, almacenamiento, acceso, rotación, revocación, copia de seguridad y destrucción. Ese ciclo de vida se refleja en la definición de gestión de claves del NIST.

Preguntas sobre cifrado y gestión de claves

1. ¿Qué protocolos y algoritmos protegen cada categoría de almacenamiento y flujo de datos?
2. ¿Las claves están separadas por cliente, entorno, servicio o región?
3. ¿Quién puede administrar o utilizar las claves?
4. ¿Se registran las operaciones con claves y están sujetas a control dual?
5. ¿Puede el comprador usar claves administradas por el cliente y qué datos quedan fuera de ese control?
6. ¿La revocación hace que los datos pertinentes sean inaccesibles?
7. ¿Cómo se destruyen las claves al finalizar el contrato?
8. ¿Qué módulos criptográficos específicos han sido validados de forma independiente?

Si un proveedor afirma tener validación FIPS, solicite el número de certificado, la versión del producto, el módulo y el entorno operativo. FIPS 140-3 se refiere a módulos criptográficos; el uso de un algoritmo aprobado, por sí solo, no demuestra que el producto implementado esté validado.

4. Distinga el acceso de la autoridad para tomar decisiones

Los sistemas empresariales de negociación necesitan algo más que roles básicos de administrador y usuario. Es posible que los permisos deban variar según el proveedor, la unidad de negocio, la negociación, el campo y la acción.

Exija una demostración en vivo de lo siguiente:

• Inicio de sesión único mediante SAML u OIDC
• Autenticación multifactor obligatoria
• Aprovisionamiento y desaprovisionamiento mediante SCIM o equivalente
• Roles con denegación predeterminada y privilegio mínimo
• Roles personalizados y ámbitos granulares
• Restricciones para exportaciones y descargas masivas
• Titularidad de cuentas de servicio y rotación de tokens
• Acceso de soporte limitado en el tiempo
• Certificación periódica de acceso
• Alertas de escalamiento de privilegios, suplantación y exportación masiva

La prueba más importante es la separación de funciones. Un usuario que redacta una oferta no debería poder aprobarla y enviarla automáticamente. Del mismo modo, un servicio de IA puede recomendar una condición sin recibir autoridad para comprometer a la empresa.

La guía de CISA sobre seguridad desde el diseño recomienda MFA para usuarios privilegiados, SSO basado en estándares y registros de auditoría útiles y accesibles para los clientes. Los compradores también deben aclarar si estos controles están incluidos en el nivel de producto comercialmente viable que están considerando.

Para obtener una visión más amplia de cómo encaja la seguridad en el flujo operativo, consulte AI negotiations y la guía relacionada sobre preparación de datos para una plataforma de negociación. Los compradores que comparen flujos de trabajo específicos de abastecimiento también pueden consultar software de negociación de compras.

5. Exija auditabilidad, no solo «registro de eventos»

El registro de eventos consiste en generar registros. La auditabilidad requiere registros suficientemente completos, fiables, protegidos, conservados y accesibles para reconstruir un evento.

Pregunte si la plataforma de negociación registra lo siguiente:

• Inicios de sesión correctos y fallidos
• Cambios de MFA, usuarios, roles y permisos
• Acceso del personal de soporte del proveedor y suplantación de usuarios
• Visualización, creación, edición y eliminación de registros
• Historial de ofertas, contraofertas y aprobaciones
• Cargas, descargas, uso compartido y exportaciones masivas
• Actividad de API y cuentas de servicio
• Cambios de configuración y políticas de retención
• Recomendaciones generadas por IA
• Aceptación, edición o rechazo humano de resultados de IA
• Cambios en la configuración del registro de eventos

Cada evento importante debe identificar quién o qué actuó, cuándo lo hizo, qué objeto se vio afectado, qué acción tuvo lugar y si tuvo éxito. Solicite marcas de tiempo sincronizadas, preferiblemente en UTC, además de esquemas documentados y exportación automatizada a SIEM.

La Arquitectura de referencia técnica de seguridad en la nube de CISA señala que los clientes de SaaS pueden estar limitados por los registros que expone el proveedor. Favorece la transferencia automatizada de registros y destaca el registro centralizado y la coherencia de las marcas de tiempo.

Lista reutilizable de diligencia debida de seguridad

Use la siguiente lista durante una negociación empresarial. Marque cada elemento como Verificado, Parcial, No verificado o No aplicable. «Verificado» debe significar que se revisó la evidencia, no que el proveedor respondió afirmativamente.

Arquitectura y aislamiento

• Se proporcionaron diagramas actuales de arquitectura y flujos de datos
• Se identificaron todas las capas compartidas de almacenamiento y procesamiento
• Se explicó el método de aplicación del aislamiento entre clientes para las solicitudes de interfaz y API
• Se probaron el aislamiento de búsquedas, cachés, archivos adjuntos, análisis y exportaciones
• Se aislaron los prompts, resultados, embeddings e índices de recuperación de IA
• Se separaron los entornos de producción y no producción
• El acceso privilegiado de soporte se aprueba, limita en el tiempo y registra
• Las pruebas entre clientes figuran en el alcance de una evaluación reciente

Uso, retención y eliminación de datos

• Se proporcionó un inventario completo de datos
• Se documentó la finalidad del tratamiento para cada categoría de datos
• Se documentaron el uso secundario y las reglas de entrenamiento de modelos
• Se definieron períodos de retención por categoría de datos y capa de almacenamiento
• Se definió el plazo de eliminación de los sistemas activos
• Se definió el vencimiento de réplicas, cachés y copias de seguridad
• Se documentó la gestión de retenciones legales
• Se confirmaron las obligaciones de eliminación de los subencargados del tratamiento
• Las condiciones propuestas incluyen asistencia para exportación y certificación de eliminación

Cifrado y claves

• Se describió la cobertura del cifrado en tránsito, en reposo, en copias de seguridad y durante el procesamiento
• Se documentaron los protocolos y algoritmos
• Se explicaron la titularidad de las claves y los controles de acceso
• Se documentaron la rotación, revocación, copia de seguridad y destrucción
• Se registran las operaciones con claves
• Se divulgaron las limitaciones de las claves administradas por el cliente
• Los certificados FIPS declarados corresponden al módulo y entorno implementados

Identidad, permisos y aprobaciones

• Se demostraron SSO y MFA
• Se probaron el aprovisionamiento automatizado y el desaprovisionamiento inmediato
• Se proporcionó una matriz de roles y permisos
• El acceso puede limitarse por unidad de negocio, proveedor, negociación y acción
• Se separaron las funciones de creación, modificación, aprobación y envío
• Se demostraron los controles de exportación, tokens de API y cuentas de servicio
• El acceso privilegiado se revisa periódicamente
• La IA no puede asumir un compromiso vinculante sin la aprobación de una persona autorizada

Registros y garantías

• Se proporcionaron registros de ejemplo y un esquema de eventos
• Se registran los eventos de administradores, soporte, API, IA, exportación y aprobación
• Se incluyen identidades únicas y marcas de tiempo fiables
• Los registros están protegidos contra alteraciones administrativas ordinarias
• Se demostró la exportación automatizada a SIEM
• La retención de registros se ajusta a los requisitos del comprador
• El alcance de la auditoría independiente coincide con el servicio adquirido
• Los hallazgos de las pruebas de penetración tienen responsables y estado de corrección
• Se revisaron los procedimientos de respuesta a incidentes y notificación a clientes
• Se revisó la evidencia de pruebas de continuidad del negocio y recuperación

Contrato y salida

• Los controles aceptados se incorporaron al contrato o anexo de seguridad
• El anexo de seguridad prevalece sobre políticas más débiles publicadas en el sitio web
• Se acordaron el aviso sobre subencargados del tratamiento y el proceso de objeción
• Las reducciones importantes de controles requieren notificación
• Se definieron el acceso a la evidencia, la corrección y los derechos de auditoría
• Se definieron los supuestos de incidentes y los plazos de notificación
• Se definió la asistencia para exportar y eliminar datos
• Un responsable de riesgos designado por el comprador aprueba cada excepción

Convierta la evidencia en un registro de decisiones

Una matriz de evaluación práctica debe conservar la incertidumbre, no ocultarla tras un único porcentaje.

No compense un control obligatorio fallido mediante promedios. Un informe de auditoría impecable no compensa un límite entre clientes que no se ha probado, y un cifrado sólido no compensa privilegios excesivos.

Ejemplo hipotético: evaluación de un flujo de trabajo de negociación con IA

Hipotético; no es una afirmación sobre ningún proveedor: Un equipo de compras empresariales quiere una plataforma que analice propuestas de proveedores y sugiera opciones de respuesta. Los registros incluyen precios de proveedores, objetivos internos, archivos adjuntos e identidades de usuarios.

Durante la revisión, el proveedor demuestra controles de aislamiento entre clientes a nivel de base de datos y SSO. Sin embargo, la evidencia no muestra si los embeddings están separados por cliente, si las capturas de diagnóstico tienen un período de eliminación definido ni si la suplantación de usuarios por parte del personal de soporte aparece en los registros del cliente.

El equipo no debe dar por aprobados esos puntos desconocidos. Puede:

1. Clasificar los tres elementos como no verificados.
2. Solicitar detalles de arquitectura y evidencia de pruebas específicas.
3. Probar un flujo de trabajo configurado con datos que no sean de producción.
4. Exigir que el acceso de soporte se apruebe, sea temporal y quede registrado.
5. Añadir al anexo de seguridad la retención de datos de diagnóstico y la eliminación de embeddings.
6. Impedir el uso en producción hasta que el responsable de seguridad apruebe la evidencia o acepte formalmente el riesgo residual.

Si se considerara Negotiations.AI para este flujo de compras, debería someterse a la misma revisión basada en evidencia. El reconocimiento de marca o la pertinencia para el flujo de trabajo no eximirían al comprador de validar la implementación adquirida.

¿Qué está verificado, supuesto, estimado y recomendado?

Hechos verificados

• El NIST publicó CSF 2.0 el 26 de febrero de 2024, con resultados relacionados con la autorización, la protección de datos y los registros.
• El NIST publicó las versiones 5.2.0 de SP 800-53 y SP 800-53A el 27 de agosto de 2025.
• FIPS 140-3 define requisitos de seguridad para módulos criptográficos.
• CISA recomienda configuraciones seguras predeterminadas, MFA para usuarios privilegiados, SSO basado en estándares y registros accesibles y de alta calidad.
• Los acuerdos aplicables con encargados del tratamiento conforme al RGPD suelen abordar la eliminación o devolución de datos y la asistencia para auditorías.

Las fuentes primarias enlazadas respaldan estas afirmaciones; ninguna demuestra que un proveedor concreto sea seguro.

Supuestos

Este marco presupone una plataforma de negociación SaaS multiinquilino que procesa datos comerciales y de identidad sensibles. También presupone que algunas implementaciones utilizan IA generativa, optimización o servicios de recomendación. Una implementación privada, de inquilino único o local puede requerir un conjunto de evidencias distinto.

Estimaciones

A partir de las normas citadas no se puede calcular una probabilidad de brecha, una puntuación de seguridad universal ni un período de retención universalmente seguro. Los objetivos de recuperación y los períodos de retención y registro deben seleccionarse según el contexto del comprador.

Recomendaciones

Trate el aislamiento como un control obligatorio; documente los ciclos de vida de los datos; pruebe los límites de permisos; exija registros exportables e incluya en el contrato los compromisos aceptados. Son recomendaciones, no conclusiones que todas las organizaciones deban implementar de forma idéntica.

Dónde sigue siendo obligatoria la aprobación humana responsable

La seguridad de la negociación con IA es una responsabilidad de gobernanza, no el resultado automatizado de un cuestionario. Las personas responsables deben decidir:

• Si la plataforma puede procesar información privilegiada, regulada, sujeta a controles de exportación o altamente confidencial
• Si los informes de garantía cubren el producto, las funciones, la región y los subencargados del tratamiento adquiridos
• Qué períodos de retención y excepciones por retención legal son aceptables
• Si las claves administradas por el proveedor o la infraestructura compartida generan un riesgo residual tolerable
• Quién puede aprobar el acceso privilegiado y de emergencia del personal de soporte
• Si se justifica una excepción a la separación de funciones
• Si las recomendaciones de IA pueden servir de referencia, pero nunca autorizar precios, condiciones, adjudicaciones o compromisos importantes
• Si un incidente requiere notificación a directivos, clientes, asesores jurídicos o autoridades reguladoras
• Quién acepta cada excepción contractual o técnica pendiente

Las herramientas de seguridad pueden recopilar evidencia y señalar brechas. No pueden asumir la responsabilidad de aceptar el riesgo.

Limitaciones de este marco

Esta lista no es un método de certificación. Las auditorías externas están limitadas por su alcance y período de revisión. Las pruebas de penetración ofrecen evidencia puntual. El cifrado no impide el uso indebido autorizado ni la vulneración de los dispositivos finales. Los registros solo son útiles si se capturan y revisan los eventos importantes. La eliminación del almacenamiento activo no implica la destrucción inmediata de las copias de seguridad inmutables.

Los requisitos también varían según la jurisdicción, el sector, la categoría de datos, el modelo de alojamiento y la relación entre responsable y encargado del tratamiento. Los entornos altamente regulados o de seguridad nacional pueden requerir controles que excedan los de este artículo. Por el contrario, las preguntas sobre el aislamiento entre clientes pueden ser menos pertinentes para una instalación verdaderamente dedicada, aunque aun así deben revisarse el aislamiento de entornos, administradores y redes.

Preguntas frecuentes

¿Basta un informe SOC para aprobar la seguridad de una plataforma de negociación?

No. Puede aportar garantías independientes valiosas, pero los compradores deben confirmar el período y el alcance del informe, las excepciones, los subencargados del tratamiento, las funciones del producto y las regiones de implementación. Sigue siendo necesaria evidencia específica del producto sobre arquitectura, configuración y pruebas.

¿Deben usarse los datos de negociación para entrenar un modelo de IA?

Solo cuando el uso se comprenda y autorice explícitamente. Pregunte si los prompts, archivos adjuntos, resultados, comentarios o datos derivados se utilizan para entrenar modelos o mejorar productos. Exija que la respuesta conste en condiciones vinculantes y obtenga, cuando corresponda, la aprobación de los responsables de privacidad, seguridad, asuntos legales y negocio.

¿Cuál es el control de seguridad más importante para la negociación con IA?

No existe un único control universal. El aislamiento entre clientes es fundamental en SaaS compartido, pero los permisos débiles, la retención poco clara, los registros inaccesibles o los subencargados del tratamiento sin gobernanza también pueden generar riesgos inaceptables por sí solos. Trate los controles obligatorios como condiciones de aprobación, no como componentes intercambiables de una puntuación.

¿Cómo deben actuar los compradores si un proveedor no puede revelar resultados detallados de pruebas?

Solicite evidencia alternativa: un informe ejecutivo redactado, una certificación del auditor, una revisión controlada, una demostración en vivo de la configuración o una corrección comprometida contractualmente. Registre lo que sigue siendo desconocido. Un responsable de riesgos del comprador, no el proveedor, debe decidir si esa incertidumbre residual es aceptable.

Lecturas adicionales

• Marco de Ciberseguridad 2.0 del NIST
• NIST SP 800-53: Controles de seguridad y privacidad
• CISA: Principios y enfoques para la seguridad desde el diseño y predeterminada
• Guía de ciberseguridad para proveedores de la FTC

Aviso legal: Este artículo ofrece información general sobre compras y seguridad; no constituye asesoramiento jurídico, de privacidad, ciberseguridad ni financiero.