Imagine três pedidos feitos a uma IA:
“Explique como funciona uma devolução.”
“Consulte a nossa política e veja se este pedido pode ser devolvido.”
“Registre a devolução e envie a confirmação ao cliente.”
Na tela, tudo pode parecer uma conversa. Por trás dela, cada pedido exige capacidades diferentes: gerar uma explicação, recuperar informações e executar ações.
É aí que aparecem siglas como LLM, RAG e MCP, além de termos como ferramentas e agentes. Entender o papel de cada peça ajuda a escolher uma solução, conversar com fornecedores e definir quais acessos fazem sentido.
Vamos acompanhar um exemplo fictício de atendimento ao cliente para entender como essas peças se conectam.
ChatGPT e modelo de IA: qual é a diferença?
O ChatGPT é uma aplicação com a qual você interage. O modelo é um dos componentes que tornam essa experiência possível. A aplicação também pode administrar o histórico da conversa, receber arquivos e disponibilizar ferramentas, conforme seus recursos e configurações.
Essa distinção ajuda a interpretar demonstrações: quando uma aplicação pesquisa uma informação ou altera um registro, há mais trabalho acontecendo do que a geração de texto pelo modelo.
IA é um campo amplo. Dentro dele, o aprendizado de máquina permite construir sistemas que aprendem padrões a partir de dados. A IA generativa produz conteúdo, como texto, imagem ou áudio. Neste artigo, o foco são os grandes modelos de linguagem, conhecidos pela sigla LLM, e as aplicações construídas ao redor deles.
Um LLM processa texto em unidades chamadas tokens, que podem corresponder a palavras, partes de palavras ou sinais de pontuação. Ao gerar uma resposta, ele produz uma sequência de tokens condicionada pelo treinamento e pelo contexto recebido.
No nosso exemplo, o modelo pode redigir uma explicação geral sobre devoluções. Essa capacidade, por si só, não demonstra que ele conhece a política vigente da loja ou que consultou o pedido do cliente.
Contexto: o que a IA tem disponível para responder
O prompt é a entrada que usamos para orientar a tarefa. Além da pergunta, a aplicação pode enviar instruções, trechos da conversa, documentos e resultados de ferramentas.
Pense na janela de contexto como uma mesa de trabalho com espaço limitado: nela ficam os materiais disponíveis para aquela chamada ao modelo. Uma aplicação pode selecionar, resumir ou recuperar informações para organizar essa mesa.
Isso é diferente de memória persistente. Um sistema pode guardar informações fora da janela de contexto e trazê-las novamente quando necessário. Também não significa que cada conversa esteja treinando novamente o modelo: fornecer contexto e atualizar os parâmetros por treinamento são processos distintos.
Para o atendimento, a diferença é prática. Perguntar “este cliente pode devolver o produto?” sem informar a política, a data da compra ou a situação do pedido deixa lacunas. Uma resposta fluente pode esconder essas lacunas.
O próximo passo é fornecer as informações relevantes.
RAG: buscar informação antes de responder
RAG, de Retrieval-Augmented Generation, combina recuperação de informação com geração de uma resposta. Em português: o sistema busca material relevante e o inclui no contexto do modelo.
No nosso cenário, a pergunta pode ser: “Qual é a política de devolução para um produto comprado há dez dias?” O sistema recupera trechos da política da loja, e o modelo usa esse material para elaborar a resposta.
O fluxo básico é:
Pergunta → busca nas fontes → trechos recuperados junto da pergunta → modelo → resposta.
A recuperação pode usar palavras-chave, busca vetorial — que compara representações numéricas do conteúdo — ou uma combinação das duas. RAG não exige uma única tecnologia de busca. A documentação da Microsoft sobre RAG explica essas alternativas.
Consultar fontes pode melhorar a resposta, mas não elimina erros. O sistema pode recuperar uma política antiga, deixar de localizar uma exceção ou interpretar incorretamente um trecho. Exibir a fonte ajuda o atendente a verificar a conclusão; a presença de uma citação não prova, sozinha, que ela está correta.
Há também uma pergunta de acesso: o documento recuperado poderia ser consultado por aquela pessoa? O mecanismo de busca precisa aplicar as permissões adequadas antes de entregar o conteúdo ao modelo. Esse controle não surge automaticamente só porque a solução usa RAG.
Ferramentas: consultar um pedido ou registrar uma devolução
A política explica as condições gerais. Para analisar um caso, o atendimento também precisa consultar o pedido: produto, data, status e valor.
É aqui que entram as ferramentas. Uma aplicação pode disponibilizar funções como consultar um pedido, abrir uma solicitação ou enviar uma mensagem. O modelo solicita uma chamada, com os argumentos necessários, e a aplicação executa a função conforme seus controles.
Esse mecanismo costuma ser chamado de function calling ou tool calling. Uma consulta poderia receber o número do pedido e retornar seu status. Outra ferramenta poderia registrar uma devolução já aprovada.
Na API da OpenAI, por exemplo, o modo estrito restringe os argumentos ao esquema definido para a função. Isso ajuda a manter a estrutura esperada, mas não comprova que o número do pedido está correto, que o usuário tem autorização ou que o sistema externo concluirá a operação. Essas verificações continuam necessárias. A documentação de function calling descreve o fluxo entre modelo, aplicação e ferramenta.
Uma distinção útil para qualquer projeto: consultar, preparar e executar podem ser permissões separadas. O atendente pode usar IA para verificar o pedido e redigir uma confirmação, enquanto o envio ou o reembolso exige uma aprovação adicional.
Agentes: coordenar os próximos passos
Um fluxo pode ter etapas definidas em código: primeiro consultar o pedido, depois verificar a política e, por último, apresentar o resultado.
Em um agente, o modelo participa da escolha dos próximos passos, usando os resultados disponíveis para decidir como avançar em direção a um objetivo. A Anthropic distingue esses agentes dos workflows com caminhos predefinidos.
No atendimento, um agente poderia consultar o pedido, perceber que falta uma informação, solicitá-la ao atendente e retomar a análise. Se uma ferramenta falhar, poderia tentar uma alternativa permitida ou encaminhar o caso para revisão.
Isso não exige autonomia irrestrita. O sistema pode permitir consultas e preparação de respostas, mas exigir aprovação para registrar um reembolso. Também pode impor limites de tentativas, tempo e valor, além de condições de parada.
“Chatbot”, “assistente” e “agente” nem sempre são categorias separadas: uma interface de chat pode dar acesso a um agente. Para avaliar uma solução, vale perguntar quem define as etapas, quais decisões o modelo pode tomar e quais ações dependem de aprovação.
MCP: um padrão para conectar aplicações a recursos e ferramentas
Cada integração precisa estabelecer como uma aplicação encontra funcionalidades e troca informações com elas. O Model Context Protocol (MCP) oferece um padrão aberto para parte dessa comunicação.
No exemplo da loja, um servidor MCP poderia disponibilizar a consulta de pedidos para aplicações compatíveis. O sistema de pedidos continua existindo, com suas APIs, regras e controles; o servidor oferece uma interface padronizada para acessá-lo.
Três participantes ajudam a entender a arquitetura:
- Host: a aplicação que oferece a experiência ao usuário e coordena as conexões.
- Cliente MCP: o componente do host que se comunica com um servidor MCP.
- Servidor MCP: o programa que expõe funcionalidades e conteúdo por meio do protocolo.
Entre os recursos que um servidor pode disponibilizar estão tools, funções que podem consultar ou alterar sistemas; resources, conteúdos que a aplicação pode acessar; e prompts, modelos de interação reutilizáveis. A especificação MCP descreve essas capacidades e sua base de comunicação.
A analogia com um “USB-C para aplicações de IA” ajuda a explicar a padronização. Mas compatibilidade não significa acesso automático: autenticação, autorização e funcionalidades suportadas ainda precisam ser configuradas e verificadas.
Um agente pode funcionar sem MCP, usando integrações diretas. Uma aplicação pode usar MCP sem operar como agente. E o RAG pode recuperar conteúdo por uma ferramenta exposta via MCP. São peças que podem ser combinadas, conforme o projeto.
O mapa completo: o papel de cada peça
Voltando à devolução, podemos organizar o cenário assim:
| Peça | Papel no exemplo |
|---|---|
| Aplicação | Recebe a solicitação e apresenta o resultado ao atendente. |
| LLM | Interpreta a solicitação e gera uma resposta com o contexto recebido. |
| RAG | Recupera trechos relevantes da política de devoluções. |
| Ferramenta | Consulta o pedido ou registra uma operação autorizada. |
| Agente | Coordena os passos conforme o objetivo e os resultados. |
| MCP | Padroniza a comunicação com recursos e ferramentas disponibilizados por servidores. |
Não é uma lista de compras obrigatória. Para explicar uma política, uma aplicação com boa recuperação de documentos pode ser suficiente. Coordenar exceções e múltiplas consultas pode justificar um agente. A escolha deve acompanhar a tarefa e a capacidade de manter o sistema.
O que muda quando entram os dados da empresa
Ao conectar essas peças, vale acompanhar um caso de ponta a ponta: qual solicitação chegou, que documentos foram recuperados, qual pedido foi consultado e que ação foi executada.
Considere três situações no mesmo atendimento:
- A busca recupera uma planilha com dados de outros clientes porque a pasta estava compartilhada amplamente.
- Uma observação no pedido contém instruções maliciosas tentando induzir a IA a enviar informações para um destino externo.
- A ferramenta permite reembolsar qualquer valor, embora a tarefa só exija preparar uma solicitação para aprovação.
São problemas diferentes. O primeiro envolve exposição de dados; o segundo ilustra uma tentativa de prompt injection, na qual conteúdo recebido tenta se passar por instrução; o terceiro envolve autoridade excessiva para agir.
O desenho da solução precisa combinar permissões sobre os dados, tratamento de conteúdo não confiável, limites das ferramentas e registro das operações. Uma instrução no prompt pode orientar o comportamento, mas não substitui a autorização aplicada pelo sistema que executa a ação.
Essa discussão se conecta aos artigos sobre agentes como identidades corporativas e sobre confiança e controle na execução de agentes.
Onde o DSPM ajuda nessa conversa
Antes de ampliar os acessos de uma aplicação de IA, a organização precisa conhecer os dados que está colocando ao alcance dela.
O DSPM contribui com essa visão: descobrir dados sensíveis, entender sua exposição, identificar permissões excessivas e acompanhar riscos associados ao uso dessas informações. Esse trabalho complementa os controles da aplicação, das identidades e das ferramentas.
Para começar a conversa com a equipe ou com um fornecedor, cinco perguntas ajudam:
- Quais fontes a solução consulta e como mantém o conteúdo atualizado?
- Com qual identidade ela acessa os dados e como aplica as permissões?
- Quais ferramentas apenas consultam e quais podem modificar ou enviar informações?
- Quais ações exigem aprovação e como interromper uma execução?
- Conseguimos reconstruir quais dados foram usados e quais ações foram realizadas?
Entender as siglas permite fazer perguntas melhores. No nosso exemplo, explicar uma devolução, consultar um pedido e executar um reembolso podem caber na mesma conversa, mas cada etapa depende de informações, acessos e decisões próprios.
O assessment gratuito do DSPM Brasil ajuda a identificar lacunas na maturidade de segurança de dados, incluindo acesso, fluxo e uso por IA. É um ponto de partida para essa discussão; a avaliação técnica de uma aplicação ou agente exige examinar também seus controles específicos.
Referências
Fontes consultadas em 21/09/2026:
