Checklist de prontidão de dados para o Agentforce

Prontidão de dados para o Agentforce é o estado em que seus registros do Salesforce estão completos, consistentes, válidos, atuais, sem duplicatas e livres de PII exposto, de modo que os agentes de IA recuperem contexto preciso e gerem respostas confiáveis. Seus dados estão prontos para o Agentforce quando cada uma dessas seis condições é medida e atinge um limiar definido, não presumida. Este checklist traz os itens a verificar, o motivo pelo qual cada um importa e a métrica do DQS que o mede.

Os agentes do Agentforce recuperam registros do Salesforce, geram respostas embasadas em dados de CRM e executam ações em nome dos usuários. Cada um desses passos lê seus dados como fonte da verdade. Se um campo está vazio, o agente não tem contexto. Se um valor está escrito de quatro formas, o agente o trata como quatro fatos. Se um comentário de Case guarda um Social Security Number, o agente pode revelá-lo. Prontidão significa fechar essas lacunas antes do deployment, não depois que um agente dá uma resposta errada em produção. Para o plano completo por fases por trás desta lista, veja Preparação para Agentforce.

Como saber se seus dados do Salesforce estão prontos para o Agentforce?

Você sabe medindo, não inspecionando registros à mão. Rode um scan do DQS em todos os objetos que o agente vai acessar e, então, compare cada métrica com um limiar-meta. Percorra as seis áreas abaixo. Cada caixa de seleção é algo que você pode verificar com um resultado de scan, então a resposta para “meus dados estão prontos” vira um número em vez de uma opinião.

O passo de medição é o que a maioria das organizações pula. Na pesquisa de dados prontos para IA da Accenture, 61% dos CXOs reconheceram que seus ativos de dados não estão prontos para IA generativa, e apenas 7% das empresas atingiram o nível de prontidão de dados necessário para escalar IA avançada. Um checklist verificado contra os resultados do scan é como você descobre de qual lado dessa linha está.

Copie o checklist para as anotações do seu projeto e marque os itens conforme os confirma.

Escopo e acesso

Defina o que o agente acessa antes de medir qualquer coisa. Um agente que lê os objetos errados falha por mais limpo que esteja o resto da sua org.

• Liste todos os objetos que o Agentforce vai ler ou escrever. O agente só recupera o que seus tópicos e ações permitem. Limite seus scans a esse conjunto exato para medir os dados que o agente realmente vê.
• Liste os campos dentro de cada objeto que o agente usa para respostas. Description, Comments, Notes e picklists chave carregam o contexto. Escanear todos os campos desperdiça esforço; escaneie os que embasam respostas.
• Confirme que a field-level security corresponde à intenção. Um agente herda o acesso do running user. Um campo oculto do usuário é invisível para o agente, então uma resposta “faltando” às vezes é uma lacuna de permissão, não de dados.
• Registre quais integrações escrevem nesses campos. Integrações são a fonte mais comum de valores inconsistentes e duplicados. Saber quem escreve diz onde corrigir a entrada, não apenas os dados.

Completude

Os agentes geram respostas vagas quando os campos que leem estão vazios. A completude é a primeira coisa a medir porque a falta de contexto é a causa mais comum de saída fraca do agente.

• Completeness Rate de 85% ou mais em cada campo que o agente usa para respostas. Um Description em branco não dá ao agente nada para embasar uma resposta. A Completeness Rate reporta o percentual de registros em que o campo tem um valor.
• Campos de contexto crítico sem brancos sistêmicos vindos de uma única fonte. Um campo deixado vazio por uma integração é uma correção de processo, não uma limpeza registro a registro. A Completeness Rate por campo isola a fonte.
• Campos exigidos pelo negócio estão preenchidos, mesmo quando não obrigatórios no schema. O Agentforce trata um campo em branco como ausência de fato. Veja Completude para entender como o DQS define “deveria estar preenchido” por objeto.

Consistência e validade

Quando o mesmo valor do mundo real aparece em várias formas, o agente trata cada uma como distinta e responde de forma inconsistente. Quando um valor quebra seu formato esperado, o retrieval downstream fica pouco confiável.

• Conformance Rate de 90% ou mais em campos de picklist e referência. Um campo Country que guarda “US”, “USA” e “United States” divide um fato em três. A Conformance Rate reporta o percentual de valores que correspondem ao seu conjunto canônico. Use Import from Field para descobrir variantes existentes e, então, defina os valores canônicos. Veja Consistência.
• Validity Rate de 90% ou mais em campos formatados. Um e-mail sem @, um número de telefone com letras ou uma data impossível são dados com os quais o agente não consegue agir — não consegue enviar, ligar ou agendar. A Validity Rate reporta o percentual de valores que passam nas suas regras de formato. Veja Validade.
• Contradições entre campos resolvidas. Um Billing State que contradiz seu Billing Country ensina ao agente uma relação falsa. As checagens de consistência revelam valores que discordam entre si.

Atualidade e duplicatas

Dados desatualizados embasam respostas em fatos que já não são verdade. Registros duplicados dão ao agente duas versões de uma mesma entidade, então a resposta depende de qual cópia ele recupera.

• Timeliness Rate atinge sua meta em campos sensíveis a data. Um Last Activity de dois anos atrás ou um Close Date no passado engana o agente. A Timeliness Rate reporta o percentual de registros atuais dentro da janela que você define. Veja Atualidade.
• Duplicate Rate baixa nos objetos que o agente lê. Quando o agente recupera um de três registros do mesmo cliente, ele responde a partir de um histórico parcial. A Duplicate Rate reporta o percentual de registros que duplicam outro. Veja Unicidade.
• Mescle ou sinalize duplicatas antes do deployment, não depois. Duplicatas criadas em formulários, importações e entrada manual se multiplicam sem monitoramento. Resolva-as para que o agente leia um registro por entidade.

PII e compliance

PII nos campos de texto que um agente lê entra no contexto da IA e pode aparecer em uma resposta gerada. Esta é a área em que uma lacuna de prontidão vira um incidente de compliance.

• PII Exposure Rate abaixo de 1% nos campos de texto que o agente acessa. SSNs e números de cartão de crédito se acumulam em Description, Comments e Notes via copia-cola e email-to-case. A PII Exposure Rate reporta o percentual de registros que contêm uma correspondência de padrão. Veja PII Detection.
• Zero correspondências de SSN ou cartão de crédito em Case Description e Comments. PII financeiro é o achado de maior severidade. Rode o scan do preset Critical para isolá-lo e, então, mascare, exclua ou descarte as correspondências confirmadas.
• Sobrescritas de padrão por campo configuradas para campos de conteúdo esperado. Um campo Email casa com o padrão de e-mail por design, o que é ruído, não exposição. As sobrescritas por campo removem esse ruído para que a taxa reflita o risco real.
• Time de compliance aprovou o scan de PII pós-remediação. GDPR, CCPA, HIPAA e PCI DSS exigem identificar e proteger PII. O DQS roda inteiramente dentro do Salesforce, então nenhum registro sai da org durante a detecção. Veja Compliance de PII no Agentforce.

Operações e monitoramento

A qualidade de dados se degrada conforme os usuários inserem novos registros. Um dataset que passa hoje acumula novos problemas em semanas, então prontidão é um estado que você mantém, não um marco que você atinge uma única vez.

• Métricas de baseline documentadas para cada dimensão no escopo. Você precisa dos números iniciais para provar que a remediação funcionou e para detectar regressão depois.
• Agendamento de scan recorrente configurado. Scans agendados transformam um snapshot pontual em uma linha de tendência. Rode PII semanalmente em objetos de texto de alto volume, completude e consistência mensalmente, e um scan completo trimestralmente.
• Propriedade da remediação atribuída por dimensão. Uma métrica sem dono não melhora. Nomeie a pessoa responsável pela completude, pelo PII e assim por diante.
• Respostas do agente testadas contra os dados remediados. Um scan aprovado prevê bom comportamento; um teste o confirma. Verifique se as saídas são precisas e se nenhum PII aparece no conteúdo gerado.

Limiares de prontidão num relance

Use esta tabela como o critério de aprovação para cada área. As metas batem com o plano de Preparação para Agentforce.

E se minha org falhar em vários itens?

Um checklist reprovado é o ponto de partida esperado, não um motivo para adiar. A maioria das orgs descobre problemas inesperados no primeiro scan. Priorize nesta ordem: PII primeiro, porque carrega risco de compliance; depois completude e consistência, porque moldam a qualidade do contexto do agente; depois validade, atualidade e unicidade. Corrija primeiro os itens de maior impacto e menor esforço, re-execute o scan e compare com sua baseline. Para um caminho de remediação passo a passo, veja Limpeza de dados do Salesforce para o Agentforce e Por que os agentes do Agentforce falham.

Próximos passos

• Preparação para Agentforce: o plano completo de prontidão por fases por trás deste checklist
• Limpeza de dados do Salesforce para o Agentforce: como remediar os itens reprovados
• PII Detection: configure a varredura de PII para os campos que os agentes leem
• Por que os agentes do Agentforce falham: os problemas de dados por trás da saída fraca do agente
• FAQ de qualidade de dados do Agentforce: respostas rápidas às dúvidas comuns de prontidão
• Como medir qualidade de dados no Salesforce: o Data Quality Score a fundo
• AI Readiness Assessment: obtenha sua pontuação atual de prontidão