O vocabulário que usamos.

Plataforma de agentes de IA da Salesforce, sucessora do Einstein. Cria agentes que consomem Data Cloud como fonte de contexto e agem sobre Sales, Service e demais clouds. Não é chatbot — é camada de execução.

Camada de contexto operacional do Salesforce. Materializa perfis em tempo real, alimenta Agentforce, Marketing e Sales. Não é só CDP — é fundação. Tratá-lo como "apenas CDP" deixa valor na mesa.

O core de vendas do Salesforce. Pipeline, oportunidades, contas, contatos, automação de processo comercial. Foi o produto original da plataforma; hoje funciona melhor quando integrado a Data Cloud e Agentforce.

O produto de atendimento do Salesforce. Casos, omnichannel, SLA, base de conhecimento. Bem implantado, vira a linguagem comum entre operação, qualidade e produto.

Plataforma para unificar identidade de cliente, segmentar e ativar em canais de marketing. Categoria de produto que Data Cloud transcende — ainda útil como conceito, mas insuficiente como definição da camada de dados.

Tanto o modelo de dados harmonizado do Data Cloud (objetos canônicos como pedidos, casos, contatos) quanto a tese estratégica do Salesforce — toda interação acontece sobre o mesmo perfil unificado.

Etapa obrigatória antes de qualquer configuração no Salesforce. Documenta passos, exceções, regras e SLAs em formato legível por humano não-iniciado e por LLM. Pular essa etapa é a maior fonte de retrabalho em projetos CRM.

Ferramenta de transformação de dados que virou padrão de fato em modelagem analítica. Usa SQL + Jinja + testes + documentação como código. O pulo do gato não é o modelo — é a documentação versionada.

ETL extrai, transforma e depois carrega — gargalo em servidores intermediários. ELT carrega bruto no warehouse e transforma lá dentro — usa o motor que já existe. A inversão é estrutural, não estética.

Conjunto típico hoje: ingestão (Fivetran/Airbyte) → warehouse (Snowflake/BigQuery/Databricks) → transformação (dbt) → BI (Tableau/Looker). Não é prescrição — é vocabulário comum entre engenheiros de dados em 2026.

Warehouse: dado estruturado, consultas SQL, foco em analítica. Lake: dado bruto em formato variado, foco em armazenamento barato. Lakehouse tenta os dois — funciona quando o problema justifica, atrapalha quando é resposta padrão.

Acordo formal entre produtor e consumidor de um dado: schema, garantias de qualidade, política de mudança. Reduz o "quebrou a pipeline porque alguém renomeou coluna" — o problema mais comum em equipes de dados.

Abordagem de modelagem (Kimball) com tabelas de fatos e dimensões. Continua valendo em 2026 — não como única arquitetura, mas como padrão para a camada analítica de consumo.

Cultura em que pessoas de negócio criam suas próprias análises a partir de modelos confiáveis. Falha quando o modelo é ruim — cada departamento cria seu "rascunho final" e a empresa perde fonte única.

Plataforma de visualização e BI (Salesforce). Excelente em exploração visual rápida sobre dados bem modelados. Não substitui modelagem nem decisão de negócio — visualiza, não pensa.

Padrão em que um LLM recupera trechos relevantes de uma base externa antes de gerar resposta. Reduz alucinação e permite usar conhecimento atualizado. A dificuldade está no "recuperar bem", não no gerar.

Modelo de linguagem treinado em vastos corpora textuais (GPT, Claude, Gemini). Útil como camada de raciocínio em pipelines de IA, perigoso como única fonte de verdade. Trate como humano júnior muito bem informado.

Representação numérica (vetor) de um texto, imagem ou outro dado. Permite calcular similaridade semântica. Base de busca vetorial e RAG. A qualidade do embedding determina a qualidade da recuperação.

Banco otimizado para busca por similaridade vetorial (Pinecone, Weaviate, pgvector). Componente típico de RAG. A escolha entre eles depende de escala, latência e ferramental existente — não de hype.

Treinar mais um LLM já pronto com dados específicos do seu domínio. Caro, demorado, raramente o primeiro movimento. RAG e prompt engineering costumam entregar 80% do valor com 10% do custo.

Disciplina de escrever instruções para LLMs que produzam saídas confiáveis. Versionado, testado e medido — não improviso. Quase sempre o primeiro experimento antes de RAG ou fine-tuning.

Processo de medir desempenho de um agente em casos reais e edge cases. Inclui taxa de acerto, tipos de erro, taxa de escalonamento, custo por interação. Sem avaliação rigorosa, agente em produção vira passivo silencioso.

Resposta de LLM que soa plausível mas é factualmente errada. RAG e prompt engineering reduzem; nunca eliminam. Por isso governança e human-in-the-loop são parte do design, não overhead.

Conjunto de práticas para operar IA com responsabilidade: logs de toda interação, auditoria de decisões, kill switch, política de retenção, processo de incidente. Não é overhead — é o que separa projeto que sobrevive a uma diretoria nova.

Modelo de engajamento Kliente 360 para projetos de IA — quatro semanas de Mapear, Prototipar, Validar e Decidir. Entrada de baixo compromisso para validar tese antes de projeto longo.

Método de entrega da Kliente 360. Cinco verbos aplicados aos três pilares: Mapear, Prototipar, Validar, Implantar, Sustentar. Híbrido entre consultoria estratégica, projeto de tecnologia e deploy rápido de IA.