Nas Sextas Ímpares #151, mostrei esta separação a propósito da gestão das minhas campanhas de anúncios. Usei um assistente de IA para me ajudar a construir a ferramenta, mas a rotina que corre todos os dias não chama nenhum modelo de linguagem para decidir o que fazer.
Construir com IA é diferente de executar com IA
Usar IA para escrever código, desenhar a arquitetura de um sistema ou ligar a serviços externos é uma coisa. Deixar que essa mesma IA decida em produção, hora a hora, se um valor deve subir ou descer é outra bem diferente, e raramente é necessária quando a decisão depende só de limites numéricos.
Na aula, expliquei como a rotina corre sem consultar um modelo de linguagem. Um cron job acorda a cada hora, vai buscar as métricas à plataforma de anúncios, compara com os limites que eu defini antes e aplica a ação correspondente. Não há ali nenhum cérebro artificial a pensar sobre o que fazer, e isso é propositado.
Se usares um modelo de linguagem para avaliar se um número é maior ou menor que outro, estás a introduzir atraso, custo de tokens a correr sem parar e o risco de a resposta vir mal formatada ou inventada. Uma condição simples em código resolve essa comparação em milissegundos e sem custo adicional. A flexibilidade dos modelos vale mais na fase de construção ou quando precisas mesmo de interpretar linguagem, como descrevo no artigo sobre planear uma aplicação com Claude Code.
O exemplo prático das campanhas do AdSummit
Uma automação de orçamentos publicitários funciona melhor quando se apoia em limites numéricos bem definidos e não em interpretações vagas. Isto ajuda a que o sistema corte ou escale investimento sem hesitar, mas os valores em si vêm sempre de decisões humanas tomadas com base no histórico do negócio.
Na live, mostrei a rotina horária que acompanha os anúncios da sétima edição do AdSummit. O sistema lê o retorno sobre o investimento, cruza com o gasto acumulado de cada conjunto de anúncios e ajusta o orçamento diário segundo intervalos que eu próprio defini com base nas seis edições anteriores do evento. A ideia era simples: vender bilhetes sem eu ter de estar o dia inteiro a abrir o gestor de anúncios.
Os critérios seguidos naquele projeto específico foram estes:
- Critério de corte: um conjunto de anúncios com ROI abaixo de 0.8 é pausado, mas só depois de ter acumulado pelo menos 60 € de investimento, para evitar decisões precipitadas com pouca informação.
- Piso de exploração: nenhum conjunto com gasto total inferior a 50 € pode ver o orçamento diário reduzido abaixo de 5 €, dando tempo a que o anúncio amadureça antes de ser descartado.
- Ajuste gradual: conjuntos com retorno comprovado sobem de patamar de orçamento, enquanto os medianos descem para valores como 15 € ou 10 € diários.
- Aviso direto: a cada ciclo horário, recebo uma mensagem no WhatsApp com o gasto do dia, o retorno atual e as alterações feitas.
Estes números pertencem àquele projeto e não servem de referência fixa para outra conta ou outro negócio. Cada operação tem a sua própria margem e o seu próprio histórico, e é aí que entra o trabalho de quem gere a campanha, não da máquina.
Onde termina a lógica determinística e começa a IA
A lógica determinística dá sempre o mesmo resultado para a mesma entrada, o que a torna previsível e fácil de auditar. A IA entra quando a informação não é tabelada, quando há linguagem a interpretar ou quando o volume de variação é demasiado grande para um conjunto fixo de regras.
Imagina um sistema de apoio ao cliente. Se basta saber o plano contratado para encaminhar o pedido, começa por uma regra e testa os planos possíveis, incluindo valores em falta. Se precisas de interpretar uma mensagem, experimenta um modelo de linguagem e compara a classificação com a leitura da equipa.
Pôr um modelo a decidir regras numéricas simples é pagar por complexidade que não precisas. Corres o risco de o modelo interpretar mal um número fora de formato ou de inventar uma justificação em texto em vez de simplesmente alterar uma variável. Para quem quer estruturar processos de negócio mais amplos sem depender só de conversas com um chatbot, vale a pena olhar para as abordagens que descrevo em usar a IA no negócio para além das conversas de chatbot.
A responsabilidade continua a ser do humano
A automação tira-te o trabalho mecânico de estar sempre a verificar dashboards, mas quem define os limites de gasto e os critérios de corte és tu, e isso não muda. Se deixares que um sistema tome decisões sobre dinheiro sem supervisão nem revisão periódica, o risco de perder capital rapidamente é real.
Na aula, insisti que um gestor de tráfego não se pode desresponsabilizar culpando a ferramenta quando os resultados não aparecem. Se um corte de orçamento prejudicou uma campanha ou se um gasto excessivo passou sem controlo, a falha estava nos limites que alguém configurou, não na automação em si. A máquina cumpre ordens; entender a economia do negócio continua a ser trabalho de quem o gere.
Vale a pena pensar num exemplo hipotético para ilustrar isto: imagina que vendes um curso de entrada a um preço simbólico, com retorno imediato fraco ou até negativo nas primeiras semanas de campanha. Se olhares só para o retorno de curto prazo, pausarias essas campanhas. Mas se esses compradores continuarem a comprar produtos mais caros ao longo dos anos seguintes, o cálculo muda completamente. Um sistema automático que só olhasse para o ROI imediato teria cortado o investimento antes de esse valor aparecer, e por isso é importante configurar a tolerância orçamental de acordo com a estratégia real de aquisição, não com um número isolado.
Tratar exceções e dados em falta
Uma automação fica vulnerável no momento em que a fonte de dados atrasa, falha ou devolve valores errados. Tratar essa ausência de informação como se fosse um resultado real de zero conversões pode levar a ações destrutivas antes que alguém repare no problema.
Se o pixel de conversões ou a API da plataforma sofrer uma falha momentânea, o retorno reportado cai para zero de forma artificial. Um sistema sem qualquer verificação interpretaria isso como mau desempenho e desligaria campanhas que, na realidade, estavam a funcionar bem. Por isso, antes de dar autonomia total a um sistema deste tipo, convém definir algumas salvaguardas:
- Janela mínima de avaliação: só avaliar conjuntos com dados contínuos durante um período definido, para não reagir a falhas passageiras de sinal.
- Paragem de emergência: se a origem de dados devolver erros ou respostas vazias, o sistema deve parar sem alterar orçamentos, em vez de assumir o pior cenário.
- Registo das decisões: guardar data, métrica usada e motivo de cada alteração, para conseguires investigar depois o que aconteceu.
- Fase de aviso antes da autonomia total: nas primeiras semanas, é mais seguro que o sistema envie recomendações em vez de agir sozinho, até ganhares confiança nos critérios definidos.
Construir fluxos que a equipa consiga acompanhar sem criar atritos é um cuidado que se aplica a várias áreas do negócio, não só a anúncios, como descrevo no guia sobre como montar um funil de leads que a equipa comercial consegue trabalhar.
Como decidir entre regras e IA no teu próprio projeto
A escolha certa depende da previsibilidade dos dados de entrada, da velocidade que precisas na resposta e da consequência financeira de um erro de processamento. Antes de acrescentares um modelo de linguagem, responde a essas perguntas e compara as opções num pequeno teste.
Antes de introduzir chamadas a modelos de IA num fluxo automatizado, vale a pena perguntar:
- Os dados de entrada são previsíveis e estruturados? Se sim, uma regra condicional em código costuma bastar.
- Existe necessidade real de interpretar linguagem natural ou intenção ambígua? Se sim, isola essa etapa numa chamada a um modelo e devolve o resultado em formato estruturado, sem misturar com a lógica de execução.
- A regra lida diretamente com dinheiro ou limites orçamentais? Se sim, o passo final de execução deve ser determinístico, sem margem para interpretação.
- Existe forma de desligar a automação manualmente se algo correr mal? Um botão de emergência acessível evita que um erro de rede ou de integração se prolongue sem controlo.
- Consegues consultar o histórico de decisões tomadas pelo sistema? Sem esse registo, fica difícil perceber o que motivou cada alteração quando algo não bate certo.
Esta divisão ajuda-te a escolher onde gastar recursos: regras para decisões definidas e IA para tarefas de interpretação. Depois mede o custo, os erros e o trabalho de revisão. Na minha formação em IA e automação, podemos discutir estas decisões a partir do processo que estás a construir.
Exemplo hipotético de triagem de pedidos: o que fica nas regras e o que é interpretação
Imagina uma equipa de suporte que recebe pedidos por email e precisa de decidir o que segue para regras fixas e o que precisa de leitura humana ou de IA. Este exemplo é hipotético, mas serve para mostrar como separar as duas partes do trabalho antes de automatizar qualquer coisa.
O primeiro passo é olhar para o tipo de pedido, não para o canal por onde chega. Um pedido de fatura em atraso tem uma estrutura previsível: número de cliente, valor, data de vencimento. Um pedido de reclamação sobre um serviço tem texto livre, tom, e às vezes ambiguidade sobre o que a pessoa quer realmente resolver.
Para o primeiro caso, a regra é simples de escrever. Se a data de vencimento passou há mais de sete dias e o valor não foi pago, envia um aviso automático e marca o registo como pendente. Não há interpretação nenhuma aqui, só verificação de condições e execução de uma ação prevista.
Para o segundo caso, a tarefa exige ler o texto, perceber se é urgente, se é um pedido de reembolso, uma queixa sobre atendimento, ou só uma pergunta mal formulada. Aqui um modelo de IA pode ajudar a classificar o pedido e a sugerir uma resposta inicial. Mas a decisão final sobre reembolsar ou não continua a precisar de alguém a validar, sobretudo se houver impacto financeiro.
Um erro comum é tentar meter tudo dentro do mesmo fluxo, como se fosse preciso escolher entre "regras" ou "IA" para o processo inteiro. Na prática, o mesmo processo pode ter as duas coisas em sequência. A regra filtra o que é óbvio e resolve sozinho, e só o que sobra passa para uma etapa de interpretação, seja ela feita por IA ou por uma pessoa.
No exemplo hipotético da equipa de suporte, isto podia funcionar assim: primeiro, uma condição verifica se o pedido tem palavras-chave associadas a urgência, como "cancelar" ou "reembolso imediato". Se tiver, vai direto para revisão humana, sem passar por IA nenhuma, porque o risco de errar é maior. Se não tiver, passa para um modelo que tenta resumir o pedido e sugerir uma categoria. Só depois é que alguém decide se aceita a sugestão ou corrige.
Este tipo de sequência tem uma vantagem prática: consegues medir onde está o esforço. Se a maior parte dos pedidos cai na parte das regras e só uma pequena fração precisa de interpretação, sabes que o investimento em afinar o modelo de IA deve ser proporcional a essa fração. Não faz sentido complicar todo o sistema com IA se noventa por cento dos casos resolvem-se com uma condição simples.
Também é preciso decidir o que fazer quando a IA não tem confiança suficiente na classificação. Uma opção é definir um limite: se a confiança for baixa, o pedido cai automaticamente na fila de revisão humana em vez de seguir sozinho. Isto evita que erros de interpretação passem sem ninguém notar, especialmente nos primeiros meses depois de pores o sistema a funcionar.
Por fim, vale a pena registar, mesmo que só para efeitos internos, quantas vezes a sugestão da IA foi aceite sem alteração e quantas vezes foi corrigida. Esse número dá uma ideia de onde a interpretação automática está a funcionar bem e onde ainda precisa de ajuste, sem depender de impressões soltas sobre "está a funcionar bem" ou "está a falhar muito".
Como desenhar uma exceção, pedir revisão humana e retomar sem duplicar ações
Uma exceção bem desenhada identifica o caso fora do previsto, para a ação automática nesse ponto, pede confirmação humana antes de continuar e regista o que já foi feito para não repetir passos quando o processo retoma. Sem estes quatro elementos, a automação arrisca-se a duplicar envios, pagamentos ou alterações.
O primeiro passo é decidir o que conta como exceção. Não é só um erro técnico, como uma ligação a falhar. Também é uma condição que a regra não previa, como um valor fora do intervalo esperado ou um registo que aparece duas vezes na mesma janela de tempo. Se não listares estes casos antes de construir a automação, vais descobri-los em produção, muitas vezes tarde demais.
Imagina um exemplo hipotético de uma rotina que ajusta o orçamento diário de uma campanha com base no custo por resultado. A regra normal diz para reduzir o orçamento dez por cento quando o custo sobe acima de um limite definido. Mas e se os dados da origem não atualizarem durante seis horas? Sem uma exceção prevista, a rotina pode continuar a aplicar reduções com base em números antigos, o que distorce a decisão.
A forma mais simples de tratar isto é separar a deteção da ação. A automação verifica primeiro se os dados são recentes e completos. Só se essa verificação passar é que avança para a regra de negócio. Se falhar, entra num estado de espera, não executa nada e sinaliza a situação a quem acompanha o processo, por exemplo através de uma mensagem no WhatsApp ou de um alerta simples.
Pedir revisão humana não significa parar todo o sistema até alguém responder. Significa isolar apenas o caso afetado. Se tens dez campanhas a correr e uma delas cai numa exceção, as outras nove continuam a funcionar normalmente com a regra original. Isto exige que o teu desenho trate cada unidade de forma independente, em vez de teres uma rotina única que processa tudo em bloco e falha por completo se um item correr mal.
Depois de alguém revisar e decidir, o sistema precisa de saber retomar sem repetir o que já tinha feito antes da pausa. Isto só é possível se guardares um registo do estado, por exemplo qual foi a última ação aplicada e a que hora. No exemplo hipotético da campanha, isso significa saber se o orçamento já tinha sido reduzido antes da falha de dados ou se ainda estava no valor original. Sem esse registo, arriscas aplicar a redução duas vezes ou, pelo contrário, nunca a aplicares.
Um critério prático para decidir se uma situação merece exceção é perguntar qual é o custo de errar. Se um erro de interpretação só gera um relatório impreciso, talvez não valha a pena parar a automação por isso. Se um erro pode duplicar um pagamento ou desligar uma campanha inteira sem motivo, então vale a pena investir tempo a desenhar a pausa e a revisão manual.
Também vale a pena definir um limite de tentativas antes de escalar para revisão humana. Se uma verificação falhar uma vez, pode ser um problema momentâneo na origem dos dados. Se falhar três ou quatro vezes seguidas, já é sinal de que algo mudou e precisa de olhos humanos, não de mais tentativas automáticas.
Quando aparecer uma exceção, precisas de saber onde o processo parou, o que já foi feito e quem vai decidir o próximo passo. Esse registo evita que a equipa tenha de reconstruir a história a partir de mensagens soltas. Podes trabalhar estas decisões na minha formação em IA e automação.
Como avaliar custo e qualidade antes de automatizar uma decisão comercial
Antes de automatizar, compara sempre custo por execução com a margem de erro aceitável. Uma regra simples é quase gratuita, mas pouco flexível; um modelo de IA custa por chamada e pode falhar. Só automatiza depois de confirmares que o resultado compensa esse equilíbrio entre preço e fiabilidade.
Começa por listar as decisões que queres automatizar e separa-as em dois grupos. No primeiro ficam as que têm um critério objetivo, como um valor que passa um limite ou uma data que expira. No segundo ficam as que exigem interpretação, como avaliar se uma mensagem de um cliente é uma reclamação grave ou um pedido de informação. Esta separação já te poupa tempo, porque o primeiro grupo raramente precisa de IA.
Para o grupo das regras, o custo de execução é praticamente irrelevante. O que interessa é a qualidade dos dados que alimentam a condição. Imagina, de forma hipotética, que queres avisar sempre que o custo por resultado de uma campanha sobe mais de 30% num dia. Se a origem dos dados falhar ou duplicar valores, a regra vai disparar avisos errados, mesmo sendo simples de escrever.
Para o grupo que exige interpretação, o cálculo é diferente. Cada chamada a um modelo tem um custo, e esse custo multiplica-se pelo volume de casos que processas por dia ou por mês. Se tens uma operação com poucas dezenas de mensagens por dia, o custo pode ser insignificante. Se tens milhares, o custo total pode tornar-se relevante e precisa de ser comparado com o tempo que pouparias a uma pessoa.
A qualidade da resposta do modelo também não é constante. Vale a pena testares a mesma tarefa várias vezes, com exemplos parecidos, e veres se a resposta muda de forma significativa. Se a variação for pequena e aceitável para o teu caso, a automação pode avançar com supervisão pontual. Se a variação for grande, precisas de rever o processo antes de dar mais autonomia ao sistema.
Um critério prático, hipotético, para decidir: se o erro de uma automação custar mais do que o tempo que ela poupa, ainda não está pronta para correr sem supervisão. Por exemplo, se uma regra mal calibrada gerar dez alertas falsos por semana e cada um exigir dez minutos de verificação manual, o custo de manutenção pode anular o ganho. Nesse caso, vale mais afinar o critério do que expandir o alcance da automação.
Também vale a pena decidires, antes de ligar qualquer automação, o que aceitas como resultado suficientemente bom. Não precisa de ser perfeito, mas precisa de ser previsível. Se conseguires descrever em que situações a automação pode falhar e o que fazes quando isso acontece, já tens uma base sólida para avançar com mais confiança.
Por fim, revê o custo e a qualidade periodicamente, não apenas no momento em que ligas a automação. Os dados de origem mudam, o volume de casos muda, e o comportamento de um modelo de IA também pode mudar com o tempo. Manter essa revisão como hábito é o que separa uma automação útil de uma automação que se torna um problema silencioso.
Como testar uma alteração às regras com casos conhecidos e registar os resultados
Antes de pores uma regra nova a correr sozinha, testa-a com casos que já conheces e cujo resultado esperado sabes de antemão. Isto permite comparar o que a regra decide com o que tu decidirias, e apanhar diferenças antes que custem dinheiro ou tempo a corrigir depois.
O primeiro passo é reunir um conjunto de casos representativos, não só os fáceis. Se a regra é sobre parar uma campanha quando o custo por resultado sobe acima de um valor, junta exemplos de campanhas que pararias, campanhas que manterias apesar de um pico temporário, e casos limite onde nem tu tens a certeza absoluta. Estes casos limite são os que mais ensinam, porque mostram onde a fronteira da regra precisa de ser ajustada.
Imagina, de forma hipotética, que estás a testar uma regra que avisa quando o custo por lead sobe 30% acima da média dos últimos sete dias. Pegas em dez situações passadas dessa campanha, aplicas a regra a cada uma manualmente e escreves ao lado o que a regra diria e o que tu decidiste na altura. Se em oito casos a regra concorda contigo, mas em dois discorda, esses dois casos merecem atenção antes de avançares.
Um desses dois casos pode revelar que a regra dispara por causa de um dia isolado com pouco volume de dados, onde uma única conversão cara distorce a média. Isto sugere que precisas de acrescentar uma condição mínima de volume antes de a regra disparar, por exemplo exigir um número mínimo de cliques ou impressões no período analisado. O outro caso pode mostrar o contrário, que a regra é demasiado lenta a reagir quando o aumento de custo é rápido e consistente, e que o período de sete dias devia ser mais curto nesse cenário específico.
Depois de ajustares a regra com base nestes casos, repete o teste com o mesmo conjunto e também com casos novos que ainda não tinhas usado. Isto evita que ajustes a regra só para os exemplos que já viste, o que a tornaria demasiado específica e menos útil para situações futuras. Uma regra boa generaliza razoavelmente bem para casos que não fizeram parte do teste original.
Regista sempre os resultados destes testes num sítio a que consigas voltar, mesmo que seja uma folha simples com data, caso testado, decisão da regra, decisão que tomarias e nota sobre o que aprendeste. Este registo serve para duas coisas: por um lado, ajuda-te a justificar porque confias na regra quando alguém perguntar; por outro, dá-te uma base para comparar quando fizeres a próxima alteração, para veres se estás a melhorar ou só a mudar o comportamento sem ganho real.
Define também um critério claro para saberes quando a regra está pronta para correr sem supervisão constante. Pode ser uma taxa de concordância mínima com as tuas decisões nos casos testados, ou um período de tempo em que a regra correu apenas a avisar, sem agir, e os avisos coincidiram com o que fazias na prática. Só depois de cumprido esse critério vale a pena dar à regra autonomia para agir sozinha, e mesmo assim com um limite claro sobre o que pode e não pode alterar sem confirmação.
Por fim, não trates este teste como um exercício único feito uma vez e esquecido. As condições do negócio mudam, os custos mudam, o comportamento dos clientes muda, e uma regra que fazia sentido há seis meses pode já não fazer sentido hoje. Marca no calendário uma revisão periódica, ainda que simples, para repetir o teste com casos recentes e confirmares que a regra continua a decidir como tu decidirias.