Por que despejar dados desorganizados não resolve nada
Se o teu CRM ou a tua base de e-mails estiverem desorganizados, a IA não vai arrumar isso por ti. Numa das Sextas Ímpares fui direto sobre isto: usar estas ferramentas em cima de dados bagunçados "vai exponenciar a bosta que tu já tens desorganizada". A frase é crua, mas resume bem o raciocínio.
O ponto de partida reside na fonte dos dados. Antes de pedir a um modelo para cruzar informação, analisar vendas ou montar um relatório, preciso de saber que os dados do outro lado estão limpos e organizados. Foi isso que descrevi como condição para os dashboards internos que hoje uso na empresa: consigo montar um relatório com uma prompt, contudo a dificuldade real está em saber o que quero e garantir que as fontes de dados estão organizadas antes de as juntar numa tabela.
Isolar cada projeto como um contexto próprio
No nível que chamei de "integrador" (o quarto de sete níveis que descrevi na aula), a pessoa já não trata todas as conversas com a IA da mesma forma. Começa a criar projetos separados, cada um com as suas instruções e os seus ficheiros, quase como uma ilha de informação.
Isto acontece, por exemplo, ao criar assistentes pessoais no ChatGPT com contexto próprio, ou projetos no Claude com instruções e ficheiros dedicados, ou ainda através do NotebookLM.
A lógica é simples: cada projeto tem uma necessidade diferente e um tipo de informação diferente. Misturar tudo numa única conversa genérica dilui o contexto e obriga o modelo a adivinhar o que é relevante. Separar por objetivo é o que permite que cada projeto "possa evoluir ao longo do tempo e possa se melhorar a si próprio".
Se estás a organizar processos comerciais separados de processos de entrega, vale a pena manter os repositórios de cada área fechados entre si, sem misturar históricos de clientes com regras internas de operação.
Como usar a IA no negócio para além das perguntas ao chatbot
Como planear uma aplicação com Claude Code antes de começar a programar
Instruções permanentes versus dados da sessão
Uma diferença que marquei entre níveis de maturidade é saber o que fica fixo nas instruções de um projeto e o que é só o dado daquele momento. Regras que não mudam, como o tom de voz que uma empresa usa com clientes, podem ficar guardadas nas instruções permanentes de um assistente ou projeto.
O que muda a cada tarefa (um ficheiro, um extrato, um texto específico) é o que entra na conversa naquele dia.
Esta separação evita repetir sempre as mesmas regras e permite que o modelo aplique consistência entre tarefas. Podes começar por identificar, no teu próprio fluxo, o que nunca muda na tua operação e isolar isso numa configuração permanente, mantendo a janela de trabalho livre para os dados variáveis.
Segurança: o cuidado que tive antes de lançar um bot público
Contei um exemplo concreto na aula: antes de lançar publicamente um bot no WhatsApp, a minha equipa e eu testámos exaustivamente tentativas de prompt injection, pois o bot acedia a ficheiros internos. Ainda assim, logo nas primeiras dez interações, quatro ou cinco pessoas tentaram enganá-lo para revelar instruções de base e dados empresariais.
O ponto que sublinhei é que "nunca houve uma altura tão boa na vida para ser hacker", precisamente porque muita gente publica coisas na internet sem cuidado, achando que um link "escondido" está protegido. Não está. Num projeto de vibe coding, a parte que consome mais tempo consiste em garantir a segurança depois, passando o projeto por revisões e por diferentes modelos até atingir um nível de confiança mais alto antes de o publicar, enquanto montar o dashboard pode demorar apenas meia hora.
Se vais dar a um modelo acesso a ficheiros ou dados sensíveis, vale a pena testar deliberadamente se ele resiste a pedidos manipulados antes de expor isso a qualquer pessoa.
Dos chats reativos às ferramentas construídas por ti
O nível mais avançado que descrevi na aula consiste em construir as tuas próprias ferramentas sobre IA. Dei exemplos concretos: um painel de aprovação criativa com clientes que substituiu o Excel desorganizado da equipa, e e-mails automáticos personalizados via Resend e Claude Code para um bolão com cerca de 80 participantes.
Nesse exemplo, peço por prompt que o sistema envie um e-mail personalizado a cada participante, com base no que cada um preencheu ou fez na aplicação, sem precisar de organizar tags manualmente como faria num CRM tradicional como o Active Campaign, que referi na aula que vou deixar de usar por pagar por um conjunto de funcionalidades das quais só aproveito uma parte.
A ideia central que trouxe é que antigamente as empresas tinham de se ajustar às ferramentas que existiam no mercado; hoje, para quem sabe construir, o processo inverte-se: constrói-se a ferramenta à medida da necessidade e não o negócio à medida da ferramenta.
O que isto muda na prática do dia a dia
O fio condutor destes exemplos é a disciplina prévia: dados limpos, contexto isolado, regras separadas e segurança testada antes da publicação. Sublinhei na aula que ninguém precisa de avançar nível a nível devagar. Vi formandos presenciais começarem no nível mais básico e, em apenas dois dias, construírem os seus próprios sistemas operacionais.
O desafio, disse eu na aula, resume-se a ultrapassar a crença de que aquilo não é para a pessoa. Quem entende como organizar contexto e dados antes de pedir à IA para trabalhar sobre eles já está a meio caminho de aproveitar isto a sério.
O caso do Resend: quando construir substitui subscrever
Quero desenvolver um pouco mais o exemplo concreto que dei sobre o bolão do Mundial, porque ilustra bem a diferença entre pagar uma ferramenta completa e construir só a fatia que preciso. No Active Campaign, para enviar um e-mail personalizado a cada participante, eu teria de organizar tags, criar automações condicionais e manter tudo isso atualizado manualmente à medida que a competição avança. Isso é trabalho de configuração recorrente, não é só o custo da subscrição.
Com o Resend integrado via Claude Code, o processo hipotético seria diferente. Eu dava uma instrução em linguagem natural, algo como pedir para verificar quem ainda não palpitou nos próximos jogos, calcular a posição de cada pessoa na classificação e gerar um e-mail com esses dados específicos para cada um dos participantes. O sistema não precisa de tags pré-configuradas porque vai buscar a informação diretamente à aplicação no momento do envio.
A diferença prática é que a personalização deixa de depender de uma estrutura montada antes, e passa a depender da qualidade da instrução dada no momento. Isto só funciona, já o disse noutra secção, se os dados de origem estiverem organizados. Se a aplicação do bolão tivesse os resultados mal registados ou os campos inconsistentes, pedir ao sistema para gerar e-mails personalizados produziria erros multiplicados, não simplificação.
Vale a pena notar que este tipo de solução foi pensado para uma necessidade interna específica com cerca de 80 participantes, não como substituto genérico de um CRM completo. Se alguém tiver uma base de milhares de contactos com necessidades de segmentação muito mais complexas, a comparação directa com uma ferramenta como o Active Campaign exigiria mais cautela antes de decidir migrar.
Nota de origem
Escrevo isto a partir da aula das Sextas Ímpares #146, "Como usar a IA melhor do que 99% das pessoas", gravada em direto a 19 de junho. Nela percorri os sete níveis de maturidade no uso de IA que costumo usar como referência, do utilizador de chatbot ao construtor de infraestrutura própria, e falei sobre os cuidados de segurança que aplico antes de publicar qualquer sistema. Vídeo completo aqui: https://www.youtube.com/watch?v=XDFoG8ohLzU.