terceiro uso muito prático é padronização. Empresas e equipes perdem muito tempo com respostas que deveriam ser consistentes: orientações de atendimento, respostas para dúvidas frequentes, mensagens de cobrança, instruções de processo, descrições de produtos, padrões de feedback. O LLM pode ajudar a criar versões base, ajustar tom e manter consistência — desde que você dê regras claras e não deixe o modelo “inventar política”. Aqui, ele funciona como um editor que aplica um estilo e uma estrutura repetidamente, com menos desgaste para a equipe.

Outro campo interessante é apoio ao pensamento, e isso inclui brainstorming, planejamento e análise inicial. LLM é bom para sugerir caminhos, levantar perguntas e organizar opções. Às vezes você não precisa que ele “decida”; você precisa que ele te ajude a ver o problema por ângulos diferentes. Você pode pedir: “liste hipóteses”, “me dê prós e contras”, “quais riscos eu não estou vendo?”, “me faça perguntas antes de eu escolher”. Esse tipo de uso é valioso porque reduz pontos cegos. É como ter alguém para conversar — só que sem depender de agenda, e sem a conversa virar só opinião: você consegue pedir estrutura e método.

Agora, indo do “uso pessoal” para o “uso em produto”, aparecem casos de uso muito comuns: assistentes internos e busca em base de conhecimento. Imagine um time com muitos documentos e processos: como solicitar reembolso, como emitir certificado, como responder dúvidas de matrícula, qual é o fluxo de atendimento. Um LLM pode ser a camada de conversa em cima disso. Só que aqui entra uma virada importante: se você solta o modelo sem uma base confiável, ele vai preencher lacunas com texto plausível. Então, em produto, o modelo precisa de limites e, idealmente, de uma base consultável, com respostas ancoradas em documentos oficiais. Sem isso, você constrói uma máquina de respostas bonitas e perigosas.

E aqui entra a parte que separa quem usa LLM com responsabilidade de quem cria problema: selecionar casos de uso pelo risco. Nem todo ganho de produtividade compensa o risco. O uso de LLM em atendimento ao cliente, por exemplo, pode reduzir demanda humana — mas também pode criar promessas falsas, orientar errado e gerar briga. O uso em documentos internos pode ser ótimo — mas pode vazar dado sensível se você não tiver cuidado com privacidade. Então a pergunta certa não é “onde eu posso usar?”, e sim “onde eu posso usar com controle e com impacto positivo?”.

Uma forma didática de escolher casos de uso é

pensar em três perguntas: (1) Isso é principalmente texto e organização? (2) Eu consigo checar com facilidade? (3) Se errar, o estrago é pequeno? Quanto mais “sim” você tiver, melhor o caso de uso. Por isso, começar com rascunhos internos, resumos e padronização costuma ser inteligente: o risco é baixo e o benefício é alto. Já começar com decisões críticas, números finais, aconselhamento jurídico ou respostas automáticas sobre reembolso e garantia é pedir para dar ruim — não porque a tecnologia é inútil, mas porque você está colocando a ferramenta no lugar errado.

Para fechar, vamos traduzir tudo isso em exemplos bem pé no chão, para você visualizar.

No escritório: transformar anotações de reunião em ata com decisões e responsáveis; criar uma resposta padrão para dúvidas recorrentes; reescrever um texto confuso para ficar claro; montar um roteiro de apresentação; adaptar um conteúdo para diferentes públicos. Em educação: transformar um conteúdo denso em explicação acessível; criar exemplos e exercícios; gerar perguntas de revisão; organizar um módulo em sequência didática. Em produto: criar um assistente interno que responde perguntas sobre processos, desde que ele se baseie em documentos aprovados e tenha rota de escalonamento para humano quando houver incerteza.

O ponto central da aula é este: LLM é valioso quando você usa como copiloto, não como “piloto automático”. Ele acelera rascunho, organização, padronização e ideação. E ele exige cuidado justamente quando o problema envolve verdade, decisão, dinheiro, direitos e risco reputacional. Se você aprende a escolher bem onde aplicar, você colhe ganhos reais sem viver apagando incêndio.

Referências bibliográficas

BENDER, Emily M.; GEBRU, Timnit; McMILLAN-MAJOR, Angelina; SHMITCHELL, Shmargaret. Sobre os perigos de papagaios estocásticos: modelos de linguagem podem ser grandes demais?. Conferência ACM sobre Justiça, Responsabilidade e Transparência (FAccT), 2021.

BROWN, Tom B. et al. Modelos de linguagem são aprendizes de poucas amostras (Language Models are Few-Shot Learners). Advances in Neural Information Processing Systems (NeurIPS), 2020.

JURAFSKY, Daniel; MARTIN, James H. Processamento de Linguagem Natural: uma introdução (Speech and Language Processing). 3ª ed. (rascunho/versão em evolução). 2023.

O’NEIL, Cathy. Armas de destruição matemática: como o Big Data aumenta a desigualdade e ameaça a democracia. São Paulo: Editora Rua do Sabão, 2016.

RUSSELL, Stuart; NORVIG, Peter. Inteligência

Artificial (Artificial Intelligence: A Modern Approach). 4ª ed. Rio de Janeiro: LTC, 2021.

SHNEIDERMAN, Ben. IA centrada no humano: confiabilidade, responsabilidade e segurança. 2022.

Aula 2 — Privacidade e segurança: o que não colocar no chat

Quando a gente fala em privacidade e segurança no uso de LLM, muita gente reage com duas ideias ruins. A primeira é o exagero: “então não posso usar para nada”. A segunda é a negligência: “ah, é só um chat, não tem perigo”. As duas estão erradas. O caminho maduro é entender o básico do risco e criar hábitos simples que evitam os erros mais comuns. Porque, na prática, o que dá problema não é usar LLM — é usar de qualquer jeito, colocando informação sensível onde não deveria.

Comecemos com uma pergunta direta: o que é “dado sensível” no dia a dia? Não é só CPF e número de cartão. É tudo aquilo que identifica uma pessoa ou expõe uma empresa de forma indevida. Nome completo, e-mail, telefone, endereço, data de nascimento, número de matrícula, dados de saúde, dados financeiros, registros escolares, conversas privadas com clientes, prints de sistemas internos, senhas, chaves de API, relatórios não publicados, cláusulas de contrato, políticas internas… tudo isso pode ser sensível dependendo do contexto. E tem um detalhe que muita gente ignora: mesmo quando você “tira o nome”, ainda dá para identificar alguém por combinação de detalhes (cidade + cargo + caso específico + data). Ou seja: anonimizar é mais do que apagar um campo; é remover pistas.

Por que isso importa? Porque, ao colar informações num chat, você está transferindo dados para um serviço. Dependendo da ferramenta e das configurações, isso pode ser armazenado por algum tempo, usado para melhorar sistemas, ficar disponível para auditorias internas, ou ser acessado em caso de incidentes. Você não controla tudo o que acontece do outro lado. Então a regra prática é simples: se você não publicaria esse dado num mural da empresa, não cole no chat. Essa frase parece dramática, mas evita muito erro.

E aqui entra uma parte importante: privacidade não é só “evitar vazamento”. É também evitar uso indevido. Às vezes o problema não é que alguém “roube” o dado; é que você compartilhou algo que não deveria com um fornecedor ou com uma ferramenta sem contrato adequado. Em ambientes profissionais, isso pode bater em compliance, sigilo contratual e legislação de proteção de dados. Não é um medo abstrato. É a vida real de quem trabalha com pessoas e informação.

Então como

usar LLM com segurança sem virar refém do medo? Com três hábitos bem pé no chão: minimização, anonimização e compartimentação.

Minimização é perguntar: “qual é o mínimo de informação que eu preciso fornecer para obter a ajuda que eu quero?”. Se você quer reescrever um e-mail, você não precisa colar o histórico inteiro com dados de cliente. Você pode colar só a parte do texto que precisa de ajuste e trocar nomes por marcadores. Se você quer um roteiro de aula, você não precisa incluir detalhes internos da instituição. Quanto menos você fornece, menos risco você cria.

Anonimização é substituir identificadores por rótulos: [ALUNO], [CLIENTE], [CIDADE], [VALOR], [DATA], [CURSO]. Só que anonimizador bom não é preguiçoso: ele tira também os “detalhes que denunciam”. Por exemplo, “aluno de 43 anos, mora na Rua X, trabalha no setor Y” pode identificar mesmo sem nome. O objetivo é manter a essência do problema e remover o que identifica.

Compartimentação é não misturar tudo. Em vez de colar uma conversa inteira de WhatsApp com o cliente, você extrai o que importa: “cliente reclama de atraso, pede reembolso, ameaça Procon”. Aí você pede ao LLM: “sugira três respostas possíveis: conciliadora, objetiva e firme; sem admitir culpa; sem prometer reembolso; orientar canal oficial”. Você deu o núcleo do caso sem expor dados do cliente.

Agora, vamos falar do erro mais comum de todos: colar segredo. Senhas, tokens, chaves de API, credenciais, links internos com acesso, prints de painel com dados reais. Isso é o tipo de coisa que não tem discussão: não entra. Se você precisa que o LLM ajude com um código que tem uma chave, você troca por “SUA_CHAVE_AQUI” e pronto. Se precisa analisar um erro de sistema, você compartilha a mensagem de erro sem anexar logs que tenham dados pessoais. Segurança é, muitas vezes, higiene básica.

Outro erro comum é usar o LLM para “resolver casos individuais” envolvendo pessoas reais. Por exemplo: “tenho um aluno com tal problema psicológico, o que eu faço?” — isso é delicado por motivos óbvios. Mesmo quando a intenção é boa, você está lidando com dado sensível e com risco ético. O caminho mais seguro é generalizar: “qual é uma abordagem pedagógica geral para apoiar alunos com dificuldades de atenção?” e, se for algo clínico, o correto é orientar para profissionais habilitados. LLM pode ajudar a organizar perguntas e opções, mas não é terapeuta nem advogado.

E tem um aspecto que muita gente esquece: privacidade também envolve resultado. Você

pode não ter colado dado sensível, mas a resposta que o modelo dá pode incentivar práticas ruins, como sugerir armazenar dados sem consentimento, coletar informações desnecessárias, ou escrever textos que expõem alguém. Por isso, quando a tarefa envolve pessoas, você precisa passar a resposta por um filtro simples: “isso respeita a pessoa? isso expõe alguém? isso assume algo sobre alguém?”. Esse filtro evita que você use uma resposta “bonita” para fazer algo impróprio.

Na prática, dá para transformar isso num protocolo rápido para uso profissional. Antes de colar qualquer coisa, você passa por três perguntas: 1) Isso tem dado pessoal? 2) Isso tem informação interna/confidencial? 3) Eu posso reescrever isso de forma genérica sem perder o objetivo? Se a resposta for “sim” para a terceira, você reescreve. Se não der para reescrever e ainda assim for necessário, então talvez o lugar certo não seja um chat genérico; pode ser uma ferramenta corporativa com governança, ou simplesmente revisão humana sem IA.

Para fechar a aula com um exercício prático, faça o seguinte: pegue um texto real que você usaria no trabalho (um e-mail, um aviso, um trecho de atendimento). Agora sanitiza: troque nomes por marcadores, remova números de documentos, retire endereços, substitua valores exatos por faixas ([R$ 100–200]), e elimine qualquer detalhe que não seja essencial. Depois disso, use o LLM para a tarefa (reescrever, tornar mais claro, criar variações). Você vai perceber duas coisas: primeiro, que dá para obter quase o mesmo resultado com bem menos risco; segundo, que o seu próprio olhar fica mais profissional, porque você passa a pensar em informação como algo que precisa de cuidado.

No fim das contas, privacidade e segurança não são um “freio” para LLM; são o que permite usar LLM com tranquilidade. Quem ignora isso até pode ganhar velocidade no começo, mas paga depois com retrabalho, desgaste e, em alguns casos, problema sério. Quem cria bons hábitos desde cedo usa a ferramenta de forma mais sustentável — e, ironicamente, mais eficiente, porque não precisa ficar apagando incêndio.

Referências bibliográficas

BRASIL. Lei nº 13.709, de 14 de agosto de 2018 (Lei Geral de Proteção de Dados Pessoais – LGPD). Diário Oficial da União, 2018.

BRASIL. Lei nº 12.965, de 23 de abril de 2014 (Marco Civil da Internet). Diário Oficial da União, 2014.

BENDER, Emily M.; GEBRU, Timnit; McMILLAN-MAJOR, Angelina; SHMITCHELL, Shmargaret. Sobre os perigos de papagaios estocásticos:

modelos de linguagem podem ser grandes demais?. Conferência ACM sobre Justiça, Responsabilidade e Transparência (FAccT), 2021.

O’NEIL, Cathy. Armas de destruição matemática: como o Big Data aumenta a desigualdade e ameaça a democracia. São Paulo: Editora Rua do Sabão, 2016.

RUSSELL, Stuart; NORVIG, Peter. Inteligência Artificial (Artificial Intelligence: A Modern Approach). 4ª ed. Rio de Janeiro: LTC, 2021.

Aula 3 — Como evoluir: do iniciante ao usuário avançado

Chegar ao final de um curso introdutório sobre LLM costuma trazer uma sensação curiosa: você já entende bem o que a ferramenta faz, já viu onde ela ajuda e onde ela atrapalha…, mas fica a pergunta: “e agora, como eu evoluo sem me perder?” Essa aula é sobre exatamente isso. Não é um convite para virar engenheiro de IA do dia para a noite, nem um empurrão para você sair usando termos técnicos só para parecer avançado. A proposta é montar um caminho realista de evolução — do iniciante que usa LLM para tarefas básicas até alguém que consegue aplicar com consistência, medir qualidade e saber quando vale investir em algo mais sofisticado.

O primeiro passo para evoluir é abandonar a ideia de que “prompt bom” é uma frase esperta. Prompt bom é uma combinação de clareza + método + controle de risco. Isso significa que você começa a tratar o LLM como parte de um processo, e não como um lugar onde você joga uma pergunta e aceita a resposta. Um usuário mais avançado não depende de inspiração; ele depende de estrutura. Por exemplo: antes de pedir a saída final, ele pede perguntas de esclarecimento, pede alternativas, pede critérios de avaliação, pede revisão e só então fecha a versão final. É um jeito de trabalhar que parece mais lento, mas reduz retrabalho e aumenta a qualidade.

Uma técnica simples que marca essa transição é criar seus próprios “modelos de prompt” para tarefas recorrentes. Se você sempre escreve e-mails, você cria um template fixo. Se você sempre produz aulas, você cria um template de aula. Se você sempre resume reuniões, você cria um template de ata. Isso é maturidade: você deixa de improvisar toda vez e passa a ter um padrão. Com o tempo, esses templates viram uma biblioteca pessoal (ou da equipe), e a qualidade sobe porque a ferramenta passa a receber briefings consistentes, com menos buraco para suposição.

Quando você quiser avançar mais um degrau, entra o prompting “com exemplos”, também chamado de few-shot: você não só descreve o que quer, você mostra um ou dois exemplos de

entrada e saída. Isso costuma melhorar muito consistência de estilo e formato, porque o modelo imita padrões com facilidade. Se você quer que ele escreva do jeito da sua escola, do jeito da sua marca, com o mesmo tipo de explicação e ela estrutura, poucos exemplos bem escolhidos fazem mais diferença do que uma lista enorme de adjetivos (“seja didático, acolhedor, objetivo…”). Exemplo é uma linguagem que o modelo entende muito bem.

Só que evoluir não é só fazer o modelo escrever melhor. Evoluir é também aprender a avaliar. Iniciante costuma avaliar pelo feeling: “parece bom”. Usuário mais avançado avalia por critérios: “atendeu objetivo?”, “respeitou restrições?”, “introduziu fatos não verificados?”, “ficou coerente com o público?”, “tem passos acionáveis?”. Uma dica prática: antes de usar LLM em algo importante, escreva uma pequena “rubrica” de avaliação. Pode ser de cinco itens, simples. Aí você pede: “gere o texto” e depois pede: “avalie o próprio texto pelos cinco critérios e corrija o que falhar”. Isso não elimina erros, mas aumenta a chance de você pegar problemas antes de publicar ou enviar.

A partir daí, você começa a esbarrar em um limite clássico: “o modelo escreve bem, mas às vezes inventa”. Quando você quer reduzir invenção e aumentar confiabilidade, há um salto de abordagem: usar o modelo com informação ancorada em documentos reais. É aqui que aparece o conceito de RAG (geração aumentada por recuperação), que, dito de forma simples, é: em vez de o modelo responder só com memória estatística, ele primeiro, busca trechos relevantes em uma base de documentos e depois responde “com base nisso”. Essa abordagem é muito usada em assistentes internos e FAQs corporativos porque diminui a chance de o modelo criar política que não existe — desde que a base esteja organizada e o sistema obrigue o modelo a citar a origem do que está dizendo.

Mas vale ser direto: RAG não é milagre. Se os documentos estiverem desatualizados, confusos ou contraditórios, a resposta vai herdar isso. Se a busca recuperar o trecho errado, o modelo pode justificar uma resposta errada com “cara de fonte”. Por isso, quando você começa a usar RAG, você precisa pensar mais como bibliotecário: qualidade da base, versionamento, atualização, e um bom mecanismo de “não sei”. Um assistente interno realmente útil não é o que responde tudo; é o que sabe quando não tem base suficiente e manda para humano.

Em algum momento, surge outra pergunta: “e ajustar o modelo para o meu caso?” Esse é

omento, surge outra pergunta: “e ajustar o modelo para o meu caso?” Esse é o território do fine-tuning (ajuste fino). O jeito honesto de pensar nisso é: fine-tuning serve mais para tom, estilo e comportamento repetitivo do que para “ensinar fatos novos”. Se você quer que o modelo escreva sempre no seu padrão, siga uma estrutura fixa, evite certos tipos de resposta, reconheça intenções comuns de usuários e responda com consistência, ajuste fino pode fazer sentido. Se o seu objetivo é manter informações atualizadas (políticas, preços, regras), isso é mais bem resolvido com base de conhecimento e recuperação, não com ajuste fino. Muita gente quer usar fine-tuning para resolver o problema errado e acaba gastando tempo e dinheiro para pouco ganho.

E aí chegamos no ponto mais “profissional” da evolução: construir uma rotina de uso responsável. Não é só tecnologia; é governança. Uma rotina boa tem três camadas: (1) o que pode e o que não pode (privacidade, dados sensíveis, decisões críticas), (2) como usar (templates, recaps, checagem), e (3) como melhorar (registrar erros, revisar prompts, atualizar base). Isso transforma o uso em algo sustentável. Em equipe, isso é ainda mais importante: sem padrão, cada pessoa usa de um jeito, a qualidade vira loteria e a marca paga o preço.

Uma prática simples que funciona muito bem é ter um “log de falhas” do LLM: toda vez que ele errar feio, você registra o que aconteceu e por quê. Foi prompt vago? Falta de contexto? Foi um tema que exige fonte externa? Foi alucinação de dado? Foi tom inadequado? Esse log vira aprendizado e vira melhoria de processo. No começo, isso parece burocracia. Depois de alguns casos, você percebe que está economizando tempo e evitando repetição do mesmo erro. Quem evolui com LLM não é quem “descobriu o prompt mágico”; é quem construiu um ciclo de melhoria.

Para fechar, eu gosto de deixar um mapa claro de próximos passos, sem fantasia. Se você está no nível iniciante, foque em: templates simples, recaps e checagem de risco. Se você está no nível intermediário, foque em: few-shot (exemplos), rubricas de avaliação, e prompts de auditoria. Se você está avançando para uso em produto ou equipe, foque em: base de conhecimento, respostas ancoradas, fluxo de escalonamento para humano, e registro de melhorias. Esse caminho é realista, aplicável e evita a armadilha mais comum: tentar “automatizar tudo” e acabar criando um sistema que dá trabalho dobrado — porque você tem que corrigir o que ele inventou.

No

fim das contas, evoluir com LLM é aprender a fazer uma coisa bem adulta: usar uma ferramenta poderosa sem idolatrar, sem temer e sem terceirizar responsabilidade. O modelo escreve, organiza e acelera. Você decide, valida e assume. Quando essa divisão de papéis fica clara, o ganho de produtividade aparece sem virar risco escondido.

Referências bibliográficas

BROWN, Tom B. et al. Modelos de linguagem são aprendizes de poucas amostras (Language Models are Few-Shot Learners). Advances in Neural Information Processing Systems (NeurIPS), 2020.

JURAFSKY, Daniel; MARTIN, James H. Processamento de Linguagem Natural: uma introdução (Speech and Language Processing). 3ª ed. (rascunho/versão em evolução). 2023.

LIU, Pengfei et al. Pré-treinamento, prompting e previsão: uma visão geral de métodos baseados em prompts em PLN (Pre-train, Prompt, and Predict: A Systematic Survey of Prompting Methods in Natural Language Processing). 2021.

LEWIS, Patrick et al. Recuperação de Passagens de Conhecimento para Geração de Linguagem (Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks). 2020.

RUSSELL, Stuart; NORVIG, Peter. Inteligência Artificial (Artificial Intelligence: A Modern Approach). 4ª ed. Rio de Janeiro: LTC, 2021.

SHNEIDERMAN, Ben. IA centrada no humano: confiabilidade, responsabilidade e segurança. 2022.

Estudo de caso do Módulo 3

Título: “O assistente interno que quase virou vazamento”
Foco do módulo: aplicações reais, privacidade/segurança e evolução responsável (processo + governança).

Contexto

A EducaMais é uma plataforma de cursos livres que cresceu rápido. O suporte está sobrecarregado com perguntas repetidas:

• “Como acesso o curso?”
• “Quando recebo o certificado?”
• “Qual a política de reembolso?”
• “Meu pagamento não compensou, e agora?”

O diretor decide criar um assistente interno para a equipe (não para alunos, ainda), com dois objetivos:

1.     reduzir tempo de atendimento;

2.     padronizar respostas.

A equipe escolhe um LLM, conecta documentos internos (políticas e manuais) e coloca o bot em uso no atendimento em 10 dias.

O piloto parece um sucesso: respostas rápidas, bem escritas, equipe empolgada. Só que, em três semanas, aparecem três problemas sérios — e todos são clássicos de quem começa a usar LLM “na prática” sem processo.

Parte 1 — Erro comum: escolher caso de uso “alto risco” cedo demais

O assistente foi liberado para responder qualquer coisa, inclusive:

• reembolso,
• chargeback,
• prazos

• de certificado,
• exceções (“meu caso é especial”).

O bot começa a dar respostas “solucionadoras” para evitar conflito.

Atendente pergunta: “Aluno pediu reembolso após 20 dias, abriu reclamação. O que respondo?”
Bot: “Podemos reembolsar excepcionalmente para manter boa reputação.”

Isso não era verdade, nem política. Era um “conselho plausível”. Resultado: o atendente usa a frase, o aluno exige, a empresa fica pressionada.

O que deu errado (raiz do problema)

• O bot foi usado como decisor, não como apoio.
• Ele entrou na zona vermelha (dinheiro/direitos) sem controle.

Como evitar

• Começar com zona verde: respostas operacionais simples (acesso, navegação, dúvidas técnicas básicas).
• Criar matriz Verde/Amarelo/Vermelho:
• Verde: bot sugere resposta pronta
• Amarelo: bot sugere + atendente valida
• Vermelho: bot só orienta “encaminhar para responsável” com checklist
• Regras explícitas: “nunca prometer reembolso, cupom, exceção, prazo não documentado”.

Parte 2 — Erro comum: privacidade tratada como detalhe

Um atendente cola no chat do assistente:

“Aluno: Maria da Silva, CPF xxx, e-mail xxx, curso X, pagamento no cartão final 1234, diz que tem depressão e está sem renda, quer reembolso.”

O bot devolve um texto “empático e perfeito”. Só que esse prompt já é um problema: dados pessoais e informação sensível (saúde) foram jogados dentro do sistema sem sanitização.

Dias depois, o time de TI faz auditoria e percebe que o histórico do bot armazenou várias conversas com dados reais.

O que deu errado

• Faltou regra operacional: “o que pode colar e o que não pode”.
• Faltou cultura de minimizar e anonimizar.
• Ninguém definiu procedimento de incidentes e retenção.

Como evitar (protocolo simples)

• Regra 1: nunca inserir CPF, cartão, endereço, e-mail, telefone, senhas, prints de sistemas.
• Regra 2: sempre substituir por marcadores:
• [ALUNO], [CURSO], [DATA], [VALOR], [MOTIVO]
• Regra 3: se for caso sensível, transformar em caso genérico:
• “Aluno alega motivo pessoal e pede exceção fora da política. Como responder sem prometer e mantendo tom humano?”
• Criar um texto padrão fixo no topo do chat: “Não cole dados pessoais ou informações confidenciais”.

Parte 3 — Erro comum: confiar que “base de documentos” resolve tudo

A EducaMais conectou PDFs internos ao assistente. Só que os documentos tinham:

• versões antigas e novas misturadas,

• trechos contraditórios (“certificado em 24h” num lugar, “em até 7 dias” em outro),
• regras diferentes para promoções antigas.

O bot recupera um trecho desatualizado e responde:

Bot: “O certificado sai em 24 horas após conclusão.”

Na prática, demorava até 7 dias. O atendente repassa para o aluno. Resultado: reclamação pública.

O que deu errado

• A base estava suja.
• Não havia “fonte obrigatória” ou versão oficial.
• Não havia mecanismo de dizer “não encontrei”.

Como evitar

• Um único documento “fonte da verdade” por tema (reembolso, certificado, acesso).
• Versionamento e data no topo de cada política.
• Regra do bot: responder citando o trecho usado; se não achar trecho confiável → encaminhar.
• Auditoria semanal: 20 respostas amostradas e checadas contra o documento oficial.

O incidente que acordou todo mundo

Um atendente, sem querer, cola um trecho de planilha interna com:

• nomes,
• e-mails,
• status de pagamento,
• observações.

Outro atendente percebe e alerta: “isso não pode”. O time entende que está a um passo de um vazamento grave.

A empresa pausa o uso do assistente por 48 horas e reorganiza o projeto do jeito certo.

Virada: como a EducaMais corrigiu e fez funcionar de verdade

1) Mudou o papel do LLM: de “responde” para “ajuda”

O bot vira copiloto:

• gera rascunhos,
• sugere estrutura,
• cria opções de resposta,
• mas nunca decide exceção.

2) Criou trilhas por risco

• Verde: acesso, navegação, problemas comuns → bot sugere resposta pronta.
• Amarelo: dúvidas com variáveis → bot faz perguntas antes (ex.: data, status do pedido).
• Vermelho: dinheiro, exceções, dados sensíveis, ameaças legais → bot só dá checklist e encaminha.

3) Implantou “higiene de dados”

• Guia de sanitização com exemplos.
• Treinamento rápido (15 min) com “pode/não pode”.
• Modelos prontos para reescrever casos sem dados pessoais.

4) Limpeza e governança da base

• Um repositório único de políticas oficiais.
• Documentos com data e responsável.
• Bot obrigado a citar origem (ou dizer “não encontrei”).

5) Ciclo de melhoria

• Log semanal de falhas:
• o que o bot errou,
• por que errou,
• qual regra/prompt/base corrigiu.

Resultado: o tempo médio de atendimento cai, mas sem promessas falsas, sem confusão e sem sustos com privacidade. Eles entendem que “IA” não é só ferramenta: é processo.

Erros comuns do Módulo 3 (resumo

direto)

1.     Começar na zona vermelha (dinheiro/direitos) sem controle.

2.     Colar dados pessoais/confidenciais no chat.

3.     Base de documentos desorganizada e desatualizada.

4.     Falta de regra de “não sei” e escalonamento humano.

5.     Não medir qualidade nem registrar falhas para melhorar.