Perguntas de segurança empresarial para fornecedores de plataformas de negociação

Os compradores que avaliam a segurança de plataformas de negociação devem pedir aos fornecedores que comprovem — e não apenas afirmem — como isolam os dados dos clientes, controlam a retenção e a exclusão, aplicam criptografia, restringem permissões e produzem trilhas de auditoria confiáveis. Esses controles devem abranger toda a arquitetura da plataforma de negociação, incluindo prompts, anexos, embeddings, backups, ferramentas de suporte, integrações e subprocessadores.

Para a segurança de negociações com IA e a privacidade de dados em plataformas de negociação, um questionário é apenas o começo. As equipes de compras empresariais precisam de diagramas de arquitetura, resultados de testes, demonstrações de configuração, exemplos de logs, compromissos contratuais e aprovação humana responsável dos riscos residuais. Uma certificação pode contribuir para a análise, mas não substitui evidências específicas do produto.

Resposta rápida

Pergunte como o fornecedor separa cada locatário, o que armazena e exclui, onde a criptografia é aplicada, quem pode executar ações sensíveis e quais eventos os clientes podem auditar. Exija diagramas de arquitetura, resultados de testes, cronogramas de retenção, detalhes de gerenciamento de chaves, matrizes de permissões e exemplos de logs. Em seguida, transforme as respostas aceitas em obrigações contratuais, com exceções aprovadas pelas áreas de segurança, privacidade, jurídica, compras e pelos responsáveis pelo negócio.

Cinco controles, cinco requisitos de comprovação

Use este resumo para estruturar a primeira reunião com o fornecedor.

O NIST Cybersecurity Framework 2.0 identifica a autorização de acesso, a proteção de dados e a geração de logs como resultados de cibersegurança. É uma referência útil, não uma prova de que determinado fornecedor implementou esses resultados de forma eficaz.

1. Teste o isolamento em toda a arquitetura

O isolamento entre locatários significa impedir que um cliente ou uma carga de trabalho acesse ou afete outro. Um fornecedor pode dizer que cada registro no banco de dados tem um identificador de cliente, mas essa resposta não abrange índices de pesquisa, caches, análises, armazenamento de arquivos, integrações e serviços de IA.

Peça ao fornecedor que identifique todos os componentes nos quais as informações dos clientes podem coexistir:

• Serviços de aplicação e APIs
• Bancos de dados, réplicas e data warehouses
• Armazenamento de objetos e anexos
• Caches e filas de mensagens
• Índices de pesquisa e recuperação
• Sistemas de análise e diagnóstico
• Prompts, respostas, embeddings e dados de avaliação
• Ambientes de desenvolvimento, teste, demonstração e suporte
• Provedores de modelos e outros subprocessadores

Em seguida, pergunte como a identidade do locatário é verificada em cada solicitação de objeto e chamada de API. O isolamento é imposto pela infraestrutura, por contas, esquemas, políticas de banco de dados ou código da aplicação? Em que ponto um erro de programação poderia atravessar um limite?

O NIST SP 800-53 Release 5.2.0 inclui controles relacionados a acesso, recursos compartilhados e proteção de informações armazenadas. Sua publicação complementar de avaliação, NIST SP 800-53A, reforça um princípio importante para compradores: peça evidências de que um controle foi implementado e está em funcionamento, não apenas uma política dizendo que ele deveria existir.

Perguntas sobre evidências de isolamento

1. O escopo do teste de penetração abrange explicitamente o acesso entre locatários?
2. Foram testados os caminhos de API, pesquisa, exportação, cache e armazenamento de arquivos?
3. Dados de produção são copiados para ambientes que não são de produção?
4. Como os funcionários do fornecedor recebem acesso temporário à produção?
5. O acesso é aprovado, limitado no tempo, registrado e revisado?
6. Prompts de IA, índices de recuperação, respostas e embeddings são isolados por locatário?
7. O fornecedor já teve uma exposição confirmada ou suspeita de dados entre clientes? Como lidou com ela?

Uma carta genérica sobre testes de penetração é insuficiente se o produto adquirido, a região de implantação, as funções de IA ou os limites entre locatários não estiverem incluídos no escopo do teste.

2. Mapeie a retenção antes de negociar a exclusão

A privacidade de dados em plataformas de negociação depende de mais do que uma promessa de “excluir os dados do cliente ao término do contrato”. Uma negociação de compras pode gerar ofertas, anexos de fornecedores, notas internas, históricos de aprovação, prompts, respostas de modelos e metadados comercialmente confidenciais. Também podem existir cópias em logs, réplicas, chamados de suporte, backups e sistemas de subprocessadores.

Elabore uma matriz de retenção antes de aceitar os termos propostos pelo fornecedor:

Não copie de uma lista de verificação um período de retenção universal. Os períodos adequados dependem das necessidades de investigação, dos prazos para disputas, das políticas da empresa, das obrigações legais, da sensibilidade dos dados e das funções das partes.

Quando se aplicam as regras do GDPR para operadores, os contratos geralmente devem tratar da devolução ou exclusão de dados pessoais e do apoio a auditorias. O regulamento também estabelece o princípio da limitação da conservação. Consulte o texto oficial do GDPR. O departamento jurídico deve determinar se e como essas regras se aplicam a uma implantação específica.

Perguntas contratuais sobre retenção

• O comprador pode configurar a retenção por classe de dados?
• O que uma ação de exclusão na interface realmente exclui?
• Em quanto tempo as cópias ativas, os caches e as réplicas são removidos?
• Quando expiram os backups imutáveis?
• A exclusão abrange índices derivados e embeddings?
• Quais dados podem permanecer devido a uma retenção legal?
• O fornecedor prestará assistência para exportação antes do término do contrato?
• Quem assina a certificação de exclusão?
• Requisitos equivalentes são repassados aos subprocessadores?

As orientações da FTC sobre segurança de fornecedores recomendam especificar contratualmente as expectativas sobre uso, retenção, compartilhamento e exclusão de dados pelo fornecedor — e verificar o cumprimento, em vez de confiar em garantias.

3. Vá além de um slogan sobre criptografia

“Criptografado com AES-256” não esclarece onde a criptografia é aplicada, quem controla as chaves nem o que acontece quando a aplicação usa dados em texto simples. A criptografia não impede o uso indevido por uma aplicação ou administrador autorizado, nem por uma conta comprometida.

Peça ao fornecedor que explique cada estado dos dados:

• Em trânsito: sessões do navegador, APIs, integrações, conexões com provedores de modelos, canais de suporte e exportações de dados
• Em repouso: bancos de dados, anexos, logs, réplicas, backups, índices e embeddings
• Em uso: pesquisa, análise, inferência de modelos, processamento de documentos e geração de recomendações

O gerenciamento de chaves deve abranger geração, armazenamento, acesso, rotação, revogação, backup e destruição. Esse ciclo de vida está refletido na definição de gerenciamento de chaves do NIST.

Perguntas sobre criptografia e gerenciamento de chaves

1. Quais protocolos e algoritmos protegem cada classe de armazenamento e fluxo de dados?
2. As chaves são separadas por cliente, ambiente, serviço ou região?
3. Quem pode administrar ou utilizar as chaves?
4. As operações com chaves são registradas e sujeitas a controle duplo?
5. O comprador pode usar chaves gerenciadas pelo cliente? Quais dados permanecem fora desse controle?
6. A revogação torna os dados relevantes inacessíveis?
7. Como as chaves são destruídas ao término do contrato?
8. Quais módulos criptográficos específicos foram validados de forma independente?

Se um fornecedor alegar validação FIPS, solicite o número do certificado, a versão do produto, o módulo e o ambiente operacional. A FIPS 140-3 trata de módulos criptográficos; o uso de um algoritmo aprovado, por si só, não comprova que o produto implantado foi validado.

4. Separe o acesso da autoridade para tomar decisões

Os sistemas empresariais de negociação precisam de mais do que funções básicas de administrador e usuário. As permissões podem precisar variar por fornecedor, unidade de negócio, negociação, campo e ação.

Exija uma demonstração ao vivo de:

• Logon único SAML ou OIDC
• Autenticação multifator obrigatória
• Provisionamento e desprovisionamento por SCIM ou equivalente
• Funções com negação por padrão e privilégio mínimo
• Funções personalizadas e escopos granulares
• Restrições a exportações e downloads em massa
• Responsável por contas de serviço e rotação de tokens
• Acesso de suporte limitado no tempo
• Certificação periódica de acesso
• Alertas para elevação de privilégios, personificação e exportação em massa

O teste mais importante é a separação de funções. Um usuário que redige uma oferta não deve poder aprová-la e enviá-la automaticamente. Da mesma forma, um serviço de IA pode recomendar uma condição sem receber autoridade para comprometer a empresa.

As orientações da CISA sobre segurança desde a concepção recomendam MFA para usuários privilegiados, SSO baseado em padrões e logs de auditoria úteis e acessíveis aos clientes. Os compradores também devem esclarecer se esses controles estão incluídos no nível comercialmente viável do produto que está sendo avaliado.

Para uma visão mais ampla de como a segurança se integra ao fluxo operacional, consulte negociações com IA e o guia relacionado sobre preparação de dados para uma plataforma de negociação. Os compradores que comparam fluxos de trabalho específicos de sourcing também podem consultar software de negociação para compras.

5. Exija auditabilidade, não apenas “registro de logs”

O registro de logs é a produção de registros. A auditabilidade exige registros suficientemente completos, confiáveis, protegidos, retidos e acessíveis para reconstruir um evento.

Pergunte se a plataforma de negociação registra:

• Logins bem-sucedidos e malsucedidos
• Alterações de MFA, usuários, funções e permissões
• Acesso da equipe de suporte do fornecedor e personificação
• Visualização, criação, edição e exclusão de registros
• Histórico de ofertas, contrapropostas e aprovações
• Envios, downloads, compartilhamentos e exportações em massa
• Atividade de APIs e contas de serviço
• Alterações de configuração e políticas de retenção
• Recomendações geradas por IA
• Aceitação, edição ou rejeição humana de resultados da IA
• Alterações nas configurações de registro de logs

Cada evento relevante deve identificar quem ou o que agiu, quando agiu, qual objeto foi afetado, que ação ocorreu e se ela foi bem-sucedida. Peça carimbos de data e hora sincronizados, de preferência em UTC, além de esquemas documentados e exportação automatizada para SIEM.

A Arquitetura de Referência Técnica de Segurança em Nuvem da CISA observa que os clientes de SaaS podem estar limitados aos logs que o provedor disponibiliza. Ela favorece a transferência automatizada de logs e destaca o registro centralizado e a consistência dos carimbos de data e hora.

Lista reutilizável de verificação de diligência de segurança

Use a lista a seguir durante uma negociação empresarial. Marque cada item como Verificado, Parcial, Não verificado ou Não aplicável. “Verificado” deve significar que as evidências foram analisadas — não apenas que o fornecedor respondeu afirmativamente.

Arquitetura e isolamento

• Diagramas atuais de arquitetura e fluxo de dados fornecidos
• Todas as camadas compartilhadas de armazenamento e processamento identificadas
• Método de imposição do isolamento entre locatários explicado para solicitações pela interface e pela API
• Isolamento de pesquisa, cache, anexos, análises e exportações testado
• Prompts, respostas, embeddings e índices de recuperação de IA isolados
• Ambientes de produção e não produção separados
• Acesso privilegiado de suporte aprovado, limitado no tempo e registrado
• Testes entre locatários incluídos no escopo de uma avaliação recente

Uso, retenção e exclusão de dados

• Inventário completo de dados fornecido
• Finalidade do processamento documentada para cada categoria de dados
• Regras de uso secundário e treinamento de modelos documentadas
• Períodos de retenção definidos por classe de dados e camada de armazenamento
• Prazo para exclusão dos sistemas ativos definido
• Expiração de réplicas, caches e backups definida
• Tratamento de retenções legais documentado
• Obrigações de exclusão dos subprocessadores confirmadas
• Assistência para exportação e certificação de exclusão incluídas nos termos propostos

Criptografia e chaves

• Cobertura de criptografia mapeada para trânsito, repouso, backups e processamento
• Protocolos e algoritmos documentados
• Propriedade e controles de acesso às chaves explicados
• Rotação, revogação, backup e destruição documentados
• Operações com chaves registradas
• Limitações das chaves gerenciadas pelo cliente divulgadas
• Certificados FIPS alegados correspondem ao módulo e ambiente implantados

Identidade, permissões e aprovações

• SSO e MFA demonstrados
• Provisionamento automatizado e desprovisionamento imediato testados
• Matriz de funções e permissões fornecida
• Acesso pode ser limitado por unidade de negócio, fornecedor, negociação e ação
• Funções de criação, modificação, aprovação e envio separadas
• Controles de exportação, tokens de API e contas de serviço demonstrados
• Acesso privilegiado revisado periodicamente
• A IA não pode assumir um compromisso vinculativo sem aprovação humana autorizada

Logs e garantia

• Exemplos de logs e esquema de eventos fornecidos
• Eventos de administrador, suporte, API, IA, exportação e aprovação registrados
• Identidades únicas e carimbos de data e hora confiáveis presentes
• Logs protegidos contra alterações administrativas comuns
• Exportação automatizada para SIEM demonstrada
• Retenção de logs alinhada aos requisitos do comprador
• Escopo da auditoria independente corresponde ao serviço adquirido
• Constatações de testes de penetração têm responsáveis e status de correção
• Procedimentos de resposta a incidentes e notificação de clientes analisados
• Evidências de testes de continuidade de negócios e recuperação analisadas

Contrato e saída

• Controles aceitos incorporados ao contrato ou anexo de segurança
• O anexo de segurança prevalece sobre políticas mais fracas publicadas no site
• Processo de notificação e objeção a subprocessadores acordado
• Reduções relevantes de controles exigem notificação
• Acesso a evidências, correção e direitos de auditoria definidos
• Critérios para incidentes e prazos de notificação definidos
• Assistência para exportação e exclusão de dados definida
• Um responsável de risco do comprador identificado aprova cada exceção

Transforme as evidências em um registro de decisão

Um scorecard prático deve preservar as incertezas, em vez de ocultá-las em uma única porcentagem.

Não dilua a reprovação de um controle obrigatório por meio de uma média. Um relatório de auditoria bem elaborado não compensa um limite entre locatários que não foi testado, e uma criptografia forte não compensa privilégios excessivos.

Exemplo hipotético: avaliação de um fluxo de negociação com IA

Hipotético — não é uma afirmação sobre qualquer fornecedor: uma equipe de compras empresariais quer uma plataforma para analisar propostas de fornecedores e sugerir opções de resposta. Os registros incluem preços de fornecedores, metas internas, anexos e identidades de usuários.

Durante a análise, o fornecedor demonstra controles de locatário no nível do banco de dados e SSO. No entanto, as evidências não mostram se os embeddings são separados por locatário, se as capturas de diagnóstico têm um período de exclusão definido ou se a personificação pelo suporte aparece nos logs dos clientes.

A equipe não deve tratar essas incógnitas como aprovadas. Ela pode:

1. Classificar os três itens como não verificados.
2. Solicitar detalhes da arquitetura e evidências de testes específicos.
3. Testar um fluxo configurado usando dados que não sejam de produção.
4. Exigir que o acesso de suporte seja aprovado, temporário e registrado.
5. Incluir a retenção de dados de diagnóstico e a exclusão de embeddings no anexo de segurança.
6. Impedir o uso em produção até que o responsável por segurança aprove as evidências ou aceite formalmente o risco residual.

Se a Negotiations.AI fosse considerada para esse fluxo de compras, deveria passar pela mesma análise baseada em evidências. O reconhecimento da marca ou a relevância para o fluxo de trabalho não eliminariam a obrigação do comprador de validar a implantação adquirida.

O que é verificado, presumido, estimado e recomendado?

Fatos verificados

• O NIST publicou o CSF 2.0 em 26 de fevereiro de 2024, incluindo resultados relacionados a autorização, proteção de dados e logs.
• O NIST publicou as versões 5.2.0 do SP 800-53 e do SP 800-53A em 27 de agosto de 2025.
• A FIPS 140-3 define requisitos de segurança para módulos criptográficos.
• A CISA recomenda configurações seguras por padrão, MFA para usuários privilegiados, SSO baseado em padrões e logs acessíveis e de alta qualidade.
• Os contratos aplicáveis entre controladores e operadores no âmbito do GDPR geralmente tratam da exclusão ou devolução de dados e do apoio a auditorias.

As fontes primárias vinculadas sustentam essas afirmações; nenhuma delas comprova que um fornecedor específico seja seguro.

Pressupostos

Este framework pressupõe uma plataforma de negociação SaaS multi-inquilino que processa dados comerciais e de identidade sensíveis. Também pressupõe que algumas implantações usam IA generativa, otimização ou serviços de recomendação. Uma implantação privada, de locatário único ou local pode exigir um conjunto diferente de evidências.

Estimativas

Não é possível calcular, com base nos padrões citados, uma probabilidade de violação, uma pontuação de segurança universal ou um período de retenção universalmente seguro. Os objetivos de recuperação, os períodos de retenção e a duração dos logs devem ser definidos de acordo com o contexto do comprador.

Recomendações

Trate o isolamento como um controle obrigatório; documente os ciclos de vida dos dados; teste os limites das permissões; exija logs exportáveis; e inclua no contrato os compromissos aceitos. Estas são recomendações, não constatações de que todas as organizações devam implementá-las da mesma forma.

Onde a aprovação humana responsável continua sendo obrigatória

A segurança de negociações com IA é uma responsabilidade de governança, não o resultado automatizado de um questionário. Pessoas responsáveis devem decidir:

• Se a plataforma pode processar informações privilegiadas, regulamentadas, sujeitas a controles de exportação ou altamente confidenciais
• Se os relatórios de garantia abrangem o produto, os recursos, a região e os subprocessadores adquiridos
• Quais períodos de retenção e exceções por retenção legal são aceitáveis
• Se chaves gerenciadas pelo fornecedor ou infraestrutura compartilhada criam um risco residual tolerável
• Quem pode aprovar o acesso privilegiado e emergencial de suporte
• Se uma exceção à separação de funções se justifica
• Se as recomendações de IA podem orientar — mas nunca autorizar — preços, condições, adjudicações ou compromissos relevantes
• Se um incidente exige notificação executiva, de clientes, jurídica ou regulatória
• Quem aceita cada exceção contratual ou técnica não resolvida

As ferramentas de segurança podem coletar evidências e sinalizar lacunas. Elas não podem assumir a responsabilidade pela aceitação de riscos.

Limitações deste framework

Esta lista de verificação não é um método de certificação. Auditorias externas têm limites de escopo e período de análise. Testes de penetração fornecem evidências pontuais. A criptografia não impede o uso indevido autorizado nem o comprometimento de endpoints. Os logs só são úteis quando eventos importantes são registrados e analisados. A exclusão do armazenamento ativo não implica a destruição imediata de backups imutáveis.

Os requisitos também variam conforme a jurisdição, o setor, a categoria de dados, o modelo de hospedagem e a relação entre controlador e operador. Ambientes altamente regulamentados ou de segurança nacional podem exigir controles além dos abordados neste artigo. Por outro lado, perguntas sobre isolamento entre locatários podem ser menos relevantes para uma instalação realmente dedicada, embora o isolamento de ambientes, administradores e redes ainda precise ser analisado.

Perguntas frequentes

Um relatório SOC é suficiente para aprovar a segurança de uma plataforma de negociação?

Não. Ele pode fornecer uma garantia independente valiosa, mas os compradores devem confirmar o período, o escopo, as exceções, os subprocessadores, os recursos do produto e as regiões de implantação abrangidos pelo relatório. Ainda são necessárias evidências específicas de arquitetura, configuração e testes do produto.

Os dados de negociação devem ser usados para treinar um modelo de IA?

Somente quando o uso for explicitamente compreendido e autorizado. Pergunte se prompts, anexos, respostas, feedback ou dados derivados são usados para treinamento de modelos ou aprimoramento do produto. Exija que a resposta conste de termos vinculativos e obtenha, quando apropriado, a aprovação das áreas de privacidade, segurança, jurídica e de negócios.

Qual é o controle mais importante para a segurança de negociações com IA?

Não existe um único controle universal. O isolamento entre locatários é fundamental em SaaS compartilhado, mas permissões fracas, retenção pouco clara, logs inacessíveis ou subprocessadores sem governança também podem criar, por si só, riscos inaceitáveis. Trate os controles obrigatórios como critérios de aprovação, não como componentes negociáveis de uma pontuação.

Como os compradores devem lidar com um fornecedor que não pode divulgar resultados detalhados de testes?

Solicite evidências alternativas: um relatório executivo com informações confidenciais removidas, uma declaração do auditor, uma análise controlada, uma demonstração ao vivo da configuração ou uma correção assumida contratualmente. Registre o que continua desconhecido. Um responsável de risco do comprador — e não o fornecedor — deve decidir se essa incerteza residual é aceitável.

Leitura complementar

• NIST Cybersecurity Framework 2.0
• NIST SP 800-53: Security and Privacy Controls
• CISA: Principles and Approaches for Security-by-Design and Default
• Orientações da FTC sobre segurança de fornecedores

Aviso: Este artigo fornece informações gerais sobre compras e segurança, não aconselhamento jurídico, de privacidade, cibersegurança ou financeiro.