Checklist de segurança para fornecedores de suporte com IA: 25 perguntas para 2026

Por que um relatório SOC 2 não basta para um fornecedor de suporte com IA?

Trabalho no lado do agente do eesel, então passo muito tempo na parte do produto que os revisores de segurança mais examinam. O eesel também já perdeu negócios exatamente por causa deste checklist. Uma plataforma de saúde dos EUA no Zendesk interrompeu a conversa no meio da demo porque, na época, não podíamos assinar um BAA. Uma grande plataforma de podcasts no Freshdesk não conseguiu avançar sem um SOC 2 concluído. Essas duas chamadas são uma grande razão para o eesel ter hoje um centro de confiança público com um calendário de auditoria datado, então vou ser honesto sobre onde estamos.

Veja o que essas chamadas me ensinaram. Um relatório SOC 2 diz que um fornecedor opera seus sistemas com cuidado: criptografia, revisões de acesso, gestão de mudanças, resposta a incidentes. Os Trust Services Criteria do AICPA cobrem segurança, disponibilidade, integridade de processamento, confidencialidade e privacidade. Esse é o piso, e você deve exigi-lo.

Mas um agente de suporte com IA é outro tipo de fornecedor. Ele não apenas armazena seus tickets. Ele os lê, os envia a um modelo de linguagem grande operado por outra empresa e, em muitas configurações, pode reembolsar um pedido ou alterar uma conta. Nenhuma categoria do SOC 2 pergunta "um cliente consegue convencer o seu bot a fazer um reembolso?"

O próprio AICPA começou a alertar os compradores sobre a mentalidade de colecionar selos. Sua página sobre SOC 2 linka um texto de 2026 intitulado "Promises of 'fast and easy' threaten SOC credibility." Então leia o relatório, confira as datas e veja se o produto de IA está de fato dentro do escopo. Depois continue.

A boa notícia é que você não precisa inventar a segunda camada. Os frameworks já existem:

Se sua equipe de segurança já usa SIG ou CAIQ, peça ao fornecedor uma cópia preenchida antes da primeira chamada. Isso economiza uma semana. O checklist abaixo é o que eu colocaria por cima, redigido para um líder de suporte e não para um auditor.

O checklist de segurança para fornecedores de suporte com IA

Marque os itens conforme o fornecedor responder. Os marcados como críticos são os que eu trataria como bloqueadores antes de um agente de IA tocar em tickets reais de clientes. O contador no topo mantém a pontuação.

O restante do artigo percorre os seis grupos, com o que 7 fornecedores de helpdesk conhecidos de fato publicam sobre cada um. Escolhi Zendesk, Freshworks, Salesforce, HubSpot, Gorgias, Help Scout e Front porque a IA deles vive dentro do helpdesk, então suas páginas de confiança são as que a maioria das equipes de suporte acaba lendo.

Eles treinam com os seus tickets?

Essa é a primeira pergunta que todo mundo faz, e as respostas são menos uniformes do que se espera. Há três perguntas distintas escondidas nela: o fornecedor treina seus próprios modelos com seus dados, o provedor do modelo por trás treina, e seus dados ajudam os agentes de outros clientes.

A maioria dos fornecedores é clara sobre o provedor do modelo. A Zendesk diz que seus subprocessadores de LLM "cannot use your Service Data to train their models", e a Front proíbe seus subprocessadores de usar dados de clientes "to train foundation models". Os modelos próprios dos fornecedores é que são interessantes:

• Zendesk treina "generic, cross-account machine learning models" para classificação com dados de serviço, após uma etapa de higienização que remove identificadores, segundo seu Trust Center. Seus recursos generativos são um caso à parte.
• Gorgias é incomumente direta: "Our AI Agent does learn from interactions from other brands," com salvaguardas para reduzir vazamentos, diz seu FAQ de segurança do AI Agent. Essa honestidade é útil. Também significa que o agente de um concorrente pode se beneficiar do seu histórico de tickets, o que algumas marcas aceitarão e outras não.
• Freshworks oferece uma saída do treinamento, mas é feita por e-mail para support@freshworks.com, segundo seu framework de processamento de dados do Freddy AI. Obtenha a confirmação por escrito.

Depois há a retenção no provedor do modelo. "Zero retenção de dados" significa que o provedor não guarda nada depois de devolver uma resposta. Zendesk, Salesforce e Front afirmam isso para seus recursos generativos. A documentação do AI Assist da Help Scout diz que a OpenAI armazena dados "for up to 30 days." Trinta dias não são um impedimento para a maioria das equipes, mas é um número com o qual o seu DPA deve concordar.

Do lado do eesel: não treinamos nem ajustamos modelos com os seus dados, e os quatro hosts de modelos abertos da nossa lista de subprocessadores operam com zero retenção de dados. Para Anthropic, OpenAI e Google, contamos com os termos comerciais de API deles, que não permitem treinar com dados de API. Se você precisa de um número de retenção por escrito para esses três, peça como parte do pacote de segurança em vez de confiar na palavra de um post de blog.

Para onde um ticket realmente vai?

Imagine um e-mail de cliente. Ele chega ao seu helpdesk, é sincronizado com o fornecedor de IA, enviado a um provedor de modelo e armazenado em um índice de busca (muitas vezes um banco de dados vetorial) e em alguns logs. Cada salto é um lugar onde ele pode ser mantido, copiado ou movido para além de uma fronteira.

Pelo Artigo 28 do GDPR, o provedor do modelo é um suboperador, e o fornecedor não pode adicionar um sem avisar você e dar a chance de se opor. Portanto, a lista de subprocessadores é um documento jurídico, não uma formalidade. É também onde a divergência aparece. O FAQ da Gorgias diz que o AI Agent usa "OpenAI, Anthropic, and internally fine-tuned LLMs," enquanto sua lista de subprocessadores, revisada pela última vez em 30 de março de 2026, lista a OpenAI como único provedor de IA. A lista da Help Scout é datada de janeiro de 2025. Nenhuma está necessariamente errada (um modelo hospedado em um provedor de nuvem pode legalmente ficar sob a linha desse provedor de nuvem, exatamente como a Salesforce explica seu uso da Anthropic), mas é uma pergunta a fazer.

A residência de dados é a outra metade, e é onde ficam as letras miúdas. Cada um destes pontos é documentado pelo próprio fornecedor:

• HubSpot: para os data centers da Austrália e do Canadá, toda linha de provedor de IA em sua página de subprocessadores mostra "United States." O data center da UE mantém o processamento de IA no Espaço Econômico Europeu.
• Salesforce: se os endpoints da região não respondem, "the request falls back to Azure OpenAI in the United States." Desligar isso exige antes o Data 360, segundo sua documentação de roteamento geográfico.
• Freshworks: para contas da Índia, Austrália e Oriente Médio/África, alguns recursos são processados nos EUA, mas "AI features that require data processing outside your primary hosting region are disabled" por padrão. Esse padrão é bom. Mais sobre o Freddy no guia de residência de dados do Freshdesk.
• Zendesk: o uso de IA "does not impact any Customer data locality commitments," exceto que produtos adquiridos, como AI Agents - Advanced, "may remain on" Google Cloud nos EUA ou na Europa "for a period of time," segundo o Trust Center.
• Front: você escolhe hospedagem nos EUA ou no EEE, mas os dados "may be otherwise processed" fora dela "as reasonably necessary," segundo sua política de hospedagem.

Nada disso está escondido. Está tudo nas páginas dos próprios fornecedores, o que lhes dá crédito. Só não está na página que o seu vendedor envia. No eesel, a produção roda por padrão na AWS nos EUA (N. Virginia), e nosso centro de confiança liga a residência completa na UE, incluindo o processamento de IA, ao plano Enterprise. Confirme o plano antes de presumir.

O que o agente pode fazer no seu helpdesk?

Esta é a seção a que eu dedicaria mais tempo, porque é onde acontece o dano real. A OWASP chama isso de Excessive Agency: ações danosas em resposta a "unexpected, ambiguous or manipulated outputs." Suas três causas raiz são funcionalidade demais, permissões demais e autonomia demais. Traduzindo para o suporte, é um agente que consegue emitir reembolsos quando só precisava consultar pedidos.

O lado jurídico também alcançou o tema. Em Moffatt v. Air Canada, um tribunal da Colúmbia Britânica rejeitou o argumento da companhia aérea de que seu chatbot era responsável pelas próprias palavras: "It makes no difference whether the information comes from a static page or a chatbot." A indenização foi pequena ($812.02 CAD no total) e é uma decisão de tribunal, não jurisprudência vinculante. Mas o princípio vale: o que o seu agente diz e faz é responsabilidade sua.

Então a pergunta ao fornecedor é concreta: mostre-me a lista de permissões e mostre-me o que acontece antes de qualquer coisa irreversível rodar.

Veja o que os fornecedores documentam:

• Gorgias tem um bom padrão. Para ações irreversíveis "like canceling an order or skipping a subscription, Customer confirmation is turned on automatically," e desligar isso significa confirmar que você entende, segundo sua documentação de ações. Mais em nosso detalhamento das ações do Gorgias AI Agent.
• HubSpot dá a cada ação do agente de cliente um nível de proteção None, Match email ou Verify email, e aconselha que alterações de acesso à conta enviem links seguros em vez de agir diretamente, segundo seu guia de configuração. Nosso guia de barreiras do Breeze cobre o lado da escalação.
• Salesforce faz os agentes "respect standard Salesforce access controls," e ações personalizadas herdam as permissões do flow ou da classe Apex por trás delas, segundo Trust and Agentforce. Poderoso, mas significa que a higiene de permissões da sua Salesforce agora é a higiene de permissões da sua IA.
• Freshworks diz que seu agente "stays within predefined flows," segundo o framework de confiança do Freddy AI. Pergunte como isso aparece na tela de administração.

Note as duas formas diferentes: Gorgias e HubSpot pedem ao cliente para confirmar, enquanto uma fila de aprovação humana pede à sua equipe. A confirmação do cliente detém um atacante que não é o dono da conta. Não impede o agente de tomar uma decisão ruim que o cliente de verdade aceita feliz, como um reembolso fora da política. Para ações que movimentam dinheiro, eu quereria uma pessoa da sua equipe no circuito, pelo menos nos primeiros meses. Nosso guia de fluxos de aprovação no suporte aprofunda onde traçar a linha.

Esta é a parte do eesel sobre a qual tenho mais opinião. Cada ação é uma permissão, definida por agente como Auto, Exige aprovação ou Desativada, e a documentação de ações e aprovações recomenda manter "refunds, cancellations and anything that costs money behind an approval." As aprovações nunca rodam sozinhas após um tempo limite, Viewers não podem aprovar, e cada aprovação registra quem decidiu e quando.

Mais duas coisas que um revisor deve verificar aqui. Primeiro, credenciais: no eesel, as requisições de saída vão apenas para domínios que você permitiu em Network Access, e o cabeçalho de autenticação é anexado no servidor, de modo que "a manipulated agent can't read out a key or token because it never had one." Segundo, toda outra porta de entrada. O eesel tem uma CLI (npx @eesel/cli) que permite a uma pessoa, um script ou um agente de código como Claude Code ou Cursor conversar com o colega, enviar conhecimento, ligar automações e limpar a fila de aprovações com eesel approvals. Todo workspace também é um servidor de Model Context Protocol. O ponto de segurança é que as gravações por CLI e MCP "follow the same action permissions as everything else," então uma ação retida continua retida, não importa por qual porta tenha entrado. Faça a mesma pergunta a cada fornecedor sobre sua API.

O escopo importa tanto quanto as permissões. A Adverscale, que ajuda pessoas com pedidos de passaporte dos EUA, roda seu agente do Zendesk apenas quando uma pessoa escreve @eesel em uma nota interna, e "She never decides a refund." A XAP, uma empresa de software educacional que trabalha com estados e faculdades dos EUA, coloca um filtro na frente do seu agente do Freshdesk para que passem apenas casos de encaminhamento e redefinições de senha do portal.

Um e-mail de cliente consegue convencer o bot a fazer algo?

Potencialmente sim, e bons fornecedores dizem isso em vez de alegar imunidade. A OWASP lista a injeção de prompt como o risco número um e observa que instruções injetadas "do not need to be human-visible/readable, as long as the content is parsed by the model." Para um agente de suporte, isso significa texto branco em um e-mail, uma linha em um PDF anexo ou um artigo de ajuda envenenado. A OWASP também observa que a geração aumentada por recuperação e o fine-tuning "do not fully mitigate" o problema. Nossa entrada de glossário sobre injeção de prompt traz a versão em linguagem simples.

O que os fornecedores documentam:

• Freshworks examina as entradas com "Azure AI Content Safety and Prompt Shields" (framework de confiança do Freddy AI).
• Salesforce tem "Prompt Defense," descrito como políticas de sistema mais detecção de injeção de prompt (Trust and Agentforce).
• Front lista um relatório "Front AI Pentest 2026" em seu centro de confiança, exatamente o tipo de documento que eu pediria a todo fornecedor.
• Zendesk, HubSpot, Gorgias e Help Scout não descrevem uma defesa contra injeção de prompt nas páginas que verifiquei. Isso não significa que não exista. Significa que você precisa perguntar.

A resposta honesta é que filtros reduzem o risco e permissões limitam o dano. O FAQ de segurança do eesel diz bem: "the protection isn't that the model can't act. It's that what it can act on is bounded, and you set the bounds." Uma ação que você não ligou simplesmente não está disponível para o modelo, não importa o que um e-mail diga. Se quiser testar isso você mesmo antes de assinar, nosso guia de testes adversariais tem prompts de teste que valem a tentativa.

Dados sensíveis são o risco irmão. A Sensitive Information Disclosure da OWASP cobre dados pessoais, detalhes financeiros, prontuários de saúde e credenciais. A armadilha que mais vejo é presumir que o mascaramento de dados pessoais do fornecedor cobre o agente de IA. A Salesforce é refrescantemente franca aqui: o mascaramento por padrões e por campos "is disabled for agents," e seu FAQ de privacidade diz que é "to improve performance and accuracy of agents" (Data Masking Limitations in Agentforce). A redação automática e o mascaramento da Zendesk ficam no complemento ADPP para planos Enterprise.

Vou cobrar o eesel pelo mesmo padrão. Nossa redação de dados pessoais cobre 15 categorias (cartões, números de seguridade social, dados bancários, chaves de API, nomes, endereços e mais) em tickets antigos antes de serem armazenados ou indexados, e falha de forma fechada: tickets que ela não consegue redigir são ignorados, não indexados em bruto. Mas é opcional por integração, vem desligada por padrão em workspaces mais novos e não se aplica a conversas ao vivo. Quando o agente busca um ticket ao vivo para redigir uma resposta, o ticket bruto chega ao modelo. Se isso importa para você, é assunto para a conversa do DPA. Nosso guia sobre redigir dados pessoais em transcrições de suporte cobre as demais opções.

Dá para ver cada resposta e ação depois?

Uma trilha de auditoria é o que transforma "achamos que o agente se comportou" em "foi isto que ele fez no ticket 4,812 e por quê." Também é o item mais frequentemente ausente especificamente para IA. O log de auditoria geral de administração é comum. Um log do que a IA fez, não:

• O log de auditoria da Front está em todos os planos, mas suas fontes listadas são Admin Copilot, API, Applications, SCIM e Teammates. O Autopilot não é uma delas.
• O histórico de atividades da HubSpot "only records HubSpot-user based actions."
• O log de auditoria da Zendesk é para planos Enterprise e acima. Para Custom Agents, a Zendesk diz que ele mostra "how an agent arrived at its responses or decisions."
• A Salesforce registra prompts, respostas e sinais de confiança no Data 360, com uma trilha de auditoria no Enterprise e acima com um complemento Einstein. O mais completo dos sete no papel.
• A Gorgias permite "view every single answer AI Agent sends, including the knowledge sources it pulls from," segundo seu FAQ.

No eesel, o Activity lista cada execução em todos os canais: o que a disparou, que conhecimento leu, que ações tomou e seu raciocínio. Você pode filtrar por aprovadas, rejeitadas e pendentes.

A visibilidade antes do lançamento importa tanto quanto depois. A revisão mais segura que já vi termina com o agente rodando nos seus próprios tickets resolvidos, sem enviar nada, para que sua equipe de segurança e seus líderes de suporte julguem respostas reais em vez de um roteiro de demo. O relatório de simulação do eesel faz isso em 20 tickets resolvidos recentemente, e nossos guias sobre testar um agente de IA antes do lançamento e conduzir um piloto de suporte com IA mostram o resto. É também a melhor defesa contra alucinações de IA: o agente da XAP "never invents a URL, a fee, a date or a policy," e deixa um marcador para a equipe quando não consegue fundamentar um detalhe.

Como os 7 fornecedores de helpdesk se comparam no papel?

Aqui está a parte documental em uma tabela, extraída do centro de confiança, do DPA e da documentação de ajuda de cada fornecedor, verificada em 20 de outubro de 2026. "Not stated" significa que não encontrei nas páginas públicas, não que não exista.

Duas linhas dessa tabela merecem um segundo olhar. Primeiro, os prazos de violação. O Artigo 33 do GDPR dá a você, o controlador, 72 horas para notificar o regulador, mas pede ao operador apenas que avise você "without undue delay." Se o contrato do seu fornecedor diz o mesmo, seu relógio de 72 horas pode começar antes mesmo de você saber. Peça um número em horas.

Segundo, HIPAA. A exigência da Help Scout de um AI Feature Healthcare Addendum separado é na verdade um bom padrão, porque força a pergunta que muitos compradores da área de saúde esquecem: o BAA cobre a IA, ou só a caixa de entrada? Nosso guia de IA em conformidade com HIPAA e o artigo sobre atendimento ao cliente com IA na saúde vão além. Se você usa especificamente um desses helpdesks, também detalhamos segurança e conformidade da Zendesk, SOC 2 do Freshdesk e SOC 2 da Gorgias.

Mais uma lei para manter na lista. O Artigo 50 do AI Act da UE exige que sistemas de IA que conversam com pessoas digam a elas que estão falando com uma IA, a menos que seja óbvio, e esse dever vale desde 2 de agosto de 2026. Se você atende clientes da UE, verifique se o fornecedor deixa você configurar esse aviso.

Como conduzir a revisão sem travar o projeto?

Revisões de segurança de ferramentas de IA costumam morrer em uma fila, não em um "não". Esta é a ordem em que eu a conduziria, o que normalmente cabe em duas semanas:

1. Peça o pacote no primeiro dia. Relatório SOC 2 ou calendário de auditoria, DPA, lista de subprocessadores e um CSA AI-CAIQ ou SIG Lite preenchido. Um fornecedor que leva uma semana para enviar isso está dizendo algo a você.
2. Passe pelos 10 itens críticos acima em uma chamada. Treinamento, aprendizado entre clientes, retenção, provedores de modelos, permissões por ação, aprovações para movimentação de dinheiro, injeção de prompt, log de ações, escopo do SOC 2. Obtenha as respostas por escrito depois.
3. Mapeie o caminho dos dados para a sua região. Desenhe os cinco saltos do diagrama acima com as respostas reais do fornecedor. As exceções de residência aparecem aqui.
4. Comece o agente em modo rascunho. Apenas notas internas, nada enviado aos clientes. A Timengo, fornecedora dinamarquesa de e-mail seguro cujos clientes incluem municípios e escolas, roda o eesel assim no Freshdesk: "The engineer sends; eesel does not."
5. Amplie as permissões uma ação por vez. Observe o log, depois passe a etiquetagem para automático, depois as primeiras respostas, e mantenha os reembolsos sob aprovação pelo maior tempo.

Se você ainda está decidindo se vai comprar, construir ou comprar IA para suporte cobre o caminho interno, e como trocar de fornecedor de suporte com IA ajuda se você está substituindo um que falhou em uma revisão. Nosso scorecard de piloto de suporte com IA transforma o passo 4 em números de aprovado ou reprovado.

Teste o eesel com o seu checklist de segurança em mãos

Se sua equipe vai fazer esta revisão em um agente de IA para Zendesk ou Freshdesk, faça-a também no eesel. O eesel é um colega de IA para helpdesk que entra na sua fila existente no Zendesk, no Freshdesk e em outros helpdesks, com cada ação em uma lista de permissões que você controla e cada execução registrada com seu raciocínio. A smava, um comparador de finanças de consumo, roda agentes do eesel com escopo definido para duas marcas em um só Zendesk, onde "Each agent has one job and a list of things it must never do."

O centro de confiança tem nosso status atual, e o pacote de segurança (políticas, DPA, respostas CAIQ ou SIG Lite) está disponível sob solicitação com NDA, normalmente em um dia útil. Você também pode começar grátis com 100 créditos na página de preços e rodar uma simulação nos seus próprios tickets antigos antes que alguém assine qualquer coisa. Teste o eesel.