Especialista em IA e automação.

Trabalho com publicidade e negócios online desde 2012. Esse percurso ensinou-me a começar pelos processos e pelos dados. Antes de escolher uma ferramenta, quero perceber como funciona o trabalho, onde surgem os erros e que decisões precisam de interpretação.

Na SpartAds, a equipa presta serviços de IA e automação para negócios que precisam de resolver fluxos de trabalho concretos. No Laboratório da IA, reúno empresários em duas mentorias por mês sobre negócios online, onde revejo projetos e partilho os bastidores técnicos daquilo que construímos.

Nas Sextas Ímpares, a minha rubrica de aulas gratuitas no YouTube, mostro código, discuto arquitetura e partilho decisões de negócio com exemplos. Nesta página encontras as aulas organizadas por tema, com ligações aos vídeos e aos minutos onde demonstro cada conceito.

O que já defendia sobre IA em 2022

No meu livro Aprende a vender com Marketing Digital, escrito em 2022, dediquei duas secções aos algoritmos e à inteligência artificial. Falava sobretudo da automação nos anúncios e da necessidade de desenvolver pensamento estratégico. Hoje aplico esse mesmo critério aos modelos de linguagem e às ferramentas que construo para os meus negócios.

A pergunta já aparecia no livro: os algoritmos ameaçam o trabalho do gestor de tráfego? A minha preocupação era perceber o que faríamos com o tempo libertado pela máquina. Havia mais espaço para estudar a oferta, interpretar resultados e melhorar a conversão. Continuar ocupado a ajustar campanhas manualmente tinha pouco interesse se essa intervenção não melhorasse o resultado.

Entretanto, o trabalho que consigo apoiar com IA alargou-se. Nas aulas mostro análise de ficheiros, construção de aplicações e integração de ferramentas. São aplicações posteriores ao livro, com responsabilidades próprias: decidir que informação pode ser usada, que ações ficam autorizadas e como confirmar o que o sistema fez. A experiência em anúncios ajuda-me a fazer perguntas melhores; cada aplicação precisa, ainda assim, de ser testada.

Gosto de começar por uma pergunta simples: se esta tarefa passar a demorar menos, onde vou usar esse tempo? Pode servir para responder melhor a clientes, rever projetos ou reduzir uma sobrecarga da equipa. Depois acompanho se isso aconteceu. O valor da mudança aparece no trabalho que conseguimos entregar e na qualidade com que o fazemos.

Como descrever um processo antes de o automatizar

Um processo só deve ser automatizado quando consegues descrever cada etapa manual sem ambiguidades, identificar as origens de dados e definir as regras de exceção. Se a equipa hesitar sobre quem valida um registo ou onde o resultado fica gravado, a automação só acelera erros já existentes.

Antes de abrires a ferramenta, fala com quem faz a tarefa. Pede-lhe que te mostre um caso do início ao fim: o que recebe, o que decide e o que faz quando falta informação. Se cada pessoa seguir um processo diferente, combina primeiro como o trabalho deve funcionar. Só depois faz sentido automatizá-lo.

Imagina, hipoteticamente, um fluxo de captação comercial em que um formulário insere uma oportunidade no CRM e notifica um responsável. A estabilidade depende das condições marginais: o que fazer se o contacto já existir com outro dono? Como tratar envios fora de horário? Sem essas respostas fechadas no papel, qualquer automação vai gerar conflitos de dados.

Para decidir onde intervir primeiro, avalio quatro variáveis: frequência da tarefa, tempo humano gasto, qualidade dos dados na origem e o custo de um erro. Rotinas frequentes com entradas padronizadas trazem retorno mais rápido. Tarefas raras, com muita decisão subjetiva, pedem primeiro organização manual, não automação imediata.

O guia de automação de processos empresariais acompanha esse percurso até à operação diária. Inclui estados, testes de exceções e responsabilidades de manutenção.

Regras condicionais e modelos de linguagem: quando usar cada abordagem

Regras condicionais servem para cálculos e validações lógicas diretas; modelos de linguagem servem para interpretar texto não estruturado ou extrair informação semântica. Confiar lógica básica de negócio a um modelo probabilístico encarece a operação e introduz falhas difíceis de prever.

Na aula O papel do gestor de tráfego na era da IA, Sextas Ímpares #151, mostrei esta separação na gestão de campanhas do AdSummit. Usei IA na fase de planeamento e escrita do código, mas o motor de execução seguiu regras fixas, como explico a partir dos 7:03. O sistema lê métricas de hora a hora e decide orçamentos com base numa matriz pré-definida, sem consultar nenhum modelo de linguagem nessa rotina.

Se precisas de verificar se um custo por aquisição ultrapassou um teto, uma condição de código resolve isso em frações de segundo e sem custo. Se precisas de classificar o sentimento de uma mensagem ou extrair dados de texto livre, aí um modelo de linguagem compensa. Misturar as duas naturezas no mesmo bloco de execução compromete a fiabilidade do sistema.

Quando usas um modelo, força saídas estruturadas, verifica a integridade da resposta e isola o negócio de alucinações. Texto gerado por IA nunca deve passar diretamente para uma ação crítica de faturação ou corte de orçamento sem validações e permissões próprias para essa ação. Nas automações que apresentei aos 35:22, a sequência é fixa: recolha de dados por API, avaliação matemática de limites, execução e aviso por WhatsApp. Podes ver mais sobre esta lógica no artigo como usar a IA no negócio para além das perguntas ao chatbot.

Quando o sistema precisa de escolher passos e utilizar ferramentas, vale avaliar os agentes de IA para empresas. Explico como definir o âmbito, limitar acessos e verificar quando o agente deve parar.

Prospeção B2B: recolher dados, qualificar e entregar uma oportunidade

A prospeção B2B com IA deve recolher dados de empresas, qualificá-las segundo critérios claros de compatibilidade com a oferta e só depois entregar contactos verificados à equipa comercial. Evita abordagens massivas e indiscriminadas: a prioridade é a qualidade e o critério, nunca simplesmente o volume de contactos gerados.

Na aula Prospeção B2B com IA, Sextas Ímpares #131, mostrei como recolher e qualificar contactos usando Apify, n8n e modelos de linguagem. Na demonstração que fiz em direto, tentei extrair contactos de consultórios de psicologia através do Instagram e o resultado saiu fraco: a maioria vinha do Brasil, não de Portugal, porque a keyword escolhida não funcionou bem para esse scraper. Já pelo Google Maps, a mesma abordagem para clínicas dentárias trouxe resultados quase todos portugueses. Isto ilustra bem que os resultados dependem muito da ferramenta e da keyword usada, e nada garante acerto à primeira.

Qualquer pontuação atribuída por IA deve manter critérios auditáveis. Se avalias setor, dimensão e presença digital, uma nota de 1 a 10 serve para ordenar prioridades, não para prever a probabilidade de fecho do negócio. É importante que a equipa comercial saiba distinguir um facto recolhido diretamente de uma inferência do modelo.

Antes de escalar a recolha para grandes volumes, vale a pena confirmar manualmente uma amostra: verificar se a atividade da empresa coincide com o nicho, se os contactos pertencem a decisores e se os critérios de descarte foram aplicados corretamente. A capacidade de extrair centenas de contactos rapidamente cria a tentação de disparar mensagens genéricas; o trabalho sério vai no sentido contrário, afinando filtros e limitando o volume a contactos com correspondência real. Aprofundo este processo no artigo como qualificar oportunidades B2B antes de contactar.

Construir software interno: o exemplo da aplicação de prognósticos com Claude Code

Construir ferramentas internas com vibe coding permite resolver problemas operacionais sem depender de plataformas genéricas de mercado, mas o resultado depende de uma fase inicial de planeamento cuidada, que defina regras, arquitetura de dados e acessos antes de escrever qualquer código. Sem esse planeamento, o risco de retrabalho é grande.

Na aula Como criei uma app com Claude Code (passo a passo), Sextas Ímpares #145, mostrei a construção de uma aplicação de prognósticos desportivos para usar com amigos durante o Mundial. O projeto envolvia autenticação, submissão de palpites bloqueados por horário, pontuação multinível, atualização automática de jogos via API externa e área administrativa. Comecei a construir numa quarta-feira ao final da tarde e, na manhã seguinte, a aplicação já estava operacional; ainda dediquei mais algumas horas depois a reforçar a segurança antes de a expor publicamente.

Antes de gerar código, escrevi num documento cada detalhe: horas de fecho das submissões, regras de pontuação, pontos de consulta da API de desporto e permissões do painel de administração. No Claude AI, pedi ao modelo que me fizesse perguntas exaustivas sobre pontos que ainda não estavam claros antes de avançar para o Claude Code, nesse caso concreto, respondi a mais de 280 perguntas antes de o ficheiro de especificação ficar pronto. Foi esse interrogatório que fechou lacunas que, de outra forma, só apareceriam a meio da construção, obrigando a reescrever partes já feitas.

Esta disciplina aplica-se a portais de clientes, calculadoras de preços ou painéis internos. Instruções vagas como "cria um painel de controlo comercial" tendem a produzir bases de dados desestruturadas e código frágil. Detalhar permissões, tipos de utilizador e fluxos de estado antes de avançar dá ao modelo contexto suficiente para construir por fases sem quebrar o que já estava feito. Desenvolvo este método com mais detalhe no artigo como planear uma aplicação com Claude Code antes de começar a programar.

Segurança antes de publicar um projeto na internet

Uma aplicação construída com apoio de modelos de linguagem só deve ser exposta na internet depois de uma revisão cuidada a credenciais, regras de base de dados e validações do lado do servidor. A rapidez com que se gera código não substitui o cuidado técnico necessário para evitar fugas de dados.

Na aula #145, dediquei um bloco de trabalho específico à segurança depois de a ferramenta estar funcional, desde a exclusão de segredos do controlo de versões até à proteção dos dados dos participantes, como explico aos 23:43 e aprofundo aos 1:23:04.

Nas ferramentas que construo antes de as publicar, sigo algumas verificações que considero mínimas:

1. Políticas de acesso na base de dados. Tabelas com dados privados devem ter regras de acesso ao nível da linha, com permissões explícitas para os dados de cada utilizador.
2. Validação de permissões no servidor. Esconder um botão na interface não impede alguém de tentar a mesma ação por outro caminho; o servidor tem de confirmar identidade e permissão a cada pedido.
3. Isolamento por identificador. O sistema deve rejeitar tentativas de acesso a registos de terceiros através de alteração de parâmetros no endereço.
4. Segregação de variáveis de ambiente. Chaves de acesso e credenciais não podem constar do repositório nem aparecer em código exposto ao navegador.
5. Validação de entradas. Formulários, uploads e parâmetros recebidos de APIs externas precisam de limites e limpeza para evitar injeções.

Costumo separar a construção da revisão. Na aula #145, mostro como uso o Codex para rever o trabalho feito com Claude Code, aos 1:38:43. O relatório dá-me pontos para investigar e corrigir; depois preciso de testar as alterações e confirmar o comportamento da aplicação.

Para rever estas camadas com exemplos, consulta as cinco regras de segurança de aplicações com IA. O percurso de desenvolvimento de aplicações com IA liga a revisão à primeira versão, aos testes e à manutenção.

Dados completos e contexto na análise de campanhas

Para diagnósticos fiáveis, precisas de alimentar a IA com dados sem distorções e com o contexto comercial do teu negócio. Um modelo não adivinha inconsistências num relatório exportado, nem avalia números desligados da realidade financeira da empresa. Sem essa base, a análise perde valor e fiabilidade.

Na aula Como usar o Claude nos meus anúncios, Sextas Ímpares #142, trabalhei a interpretação de relatórios de publicidade. Um detalhe prático mostrou um risco comum: o ficheiro exportado refletia apenas as colunas visíveis no ecrã da plataforma, aos 26:31. Se a exportação omitir métricas ou incluir totais agregados na mesma tabela, o modelo tira conclusões erradas com base em dados incompletos.

Antes de pedir análises a um assistente de IA, vale confirmar se o período está alinhado, se a moeda coincide, se a nomenclatura das campanhas é consistente e se linhas de soma geral foram removidas para não duplicar investimentos. É preciso também clarificar o que significa cada métrica de conversão: um evento de aquisição pode ser uma lead fria, uma chamada telefónica ou uma compra já concluída.

Depois, a pergunta deve refletir o contexto operacional da campanha. Avaliar a subida do custo por clique de uma semana para a outra é uma análise mecânica; perceber se essa subida é aceitável porque a conversão comercial melhorou exige cruzar dados de publicidade com dados de faturação real. Envia apenas métricas agregadas e evita transferir nomes, contactos ou moradas de clientes para plataformas públicas de IA.

Desenvolvo a preparação de perguntas e a verificação de cálculos no guia de análise de dados com IA para negócios. É uma leitura útil antes de transformar um relatório numa decisão de campanha ou de equipa.

Do playbook da equipa às instruções de uma automação

Um playbook deve permitir que outra pessoa execute um trabalho e perceba as decisões já tomadas. No livro, recomendava documentar objetivos, passos e aprendizagens para facilitar essa passagem. Ao aplicar hoje esta prática à IA, acrescento os limites de acesso, as situações que exigem revisão e a forma de interromper uma execução.

Pensa num pedido de orçamento. O documento pode explicar que informação é necessária, onde confirmar o serviço pedido e quem prepara a proposta. Acrescenta exemplos de pedidos completos e incompletos, com o motivo de cada decisão. Se uma informação essencial faltar, o processo deve pedir esclarecimento ou encaminhar o caso para alguém responsável.

Entregar esse documento a um modelo ajuda a dar contexto, mas as permissões têm de existir também na aplicação. Um assistente que prepara uma proposta não precisa, por esse motivo, de poder alterar preços, aprovar descontos ou enviar a proposta ao cliente. Uma instrução escrita para «pedir autorização» precisa de uma verificação técnica que impeça a ação enquanto essa autorização não existir.

O registo dos testes também faz parte do playbook. Guarda o caso, o resultado esperado, o que aconteceu e a correção aplicada, usando exemplos fictícios ou devidamente anonimizados. Quando mudares as instruções, uma integração ou o modelo, volta a passar pelos casos importantes. É uma aplicação atual da disciplina de aprendizagem que já defendia no livro.

Para aprofundar a parte técnica, a Anthropic explica como distinguir fluxos predefinidos de agentes e como avaliar o comportamento de agentes de IA. São referências complementares; nas minhas demonstrações de planeamento com Claude Code podes acompanhar as decisões num projeto concreto.

Operação diária: monitorização, falhas e custos

Um sistema automatizado precisa de rotinas de monitorização que confirmem a atualização dos dados e evitem ações destrutivas quando há quebras nas ligações de rede. Ignorar o tratamento de falhas e os limites de consumo transforma um projeto técnico num encargo operacional inesperado.

Uma automação fiável distingue ausência momentânea de dados de um resultado real de zero. Se uma API de pagamentos não responder durante alguns minutos, o sistema deve registar a ocorrência e tentar novo contacto de forma controlada, em vez de assumir que a faturação caiu a zero e disparar alertas falsos. Tarefas de envio de mensagens ou criação de encomendas precisam de chaves de idempotência, para que uma repetição por falha técnica não crie duplicados.

Na aula #142, expliquei a ligação entre Google Sheets, n8n e alertas de WhatsApp, aos 29:28. Um aviso útil resume apenas a anomalia detetada, indica o período em causa e liga diretamente ao registo do erro. Mensagens contínuas e genéricas geram fadiga na equipa e fazem com que incidentes reais passem despercebidos.

Vale acompanhar o consumo de chamadas a modelos e o custo de computação de cada automação. Antes de ligar um processo a milhares de registos, testar numa amostra reduzida ajuda a estimar o gasto médio e a fixar limites diários. Também compensa medir o tempo que a equipa continua a gastar a rever ou corrigir resultados do sistema, essa conta ajuda a perceber se o processo melhorou de facto. Podes ver este equilíbrio no artigo crescer um negócio online: o que aprendi sobre margem, equipa e IA.

Formação de equipas e integração de IA no negócio

A adoção de IA numa empresa falha quando é tratada como exercício teórico desligado dos objetivos de rentabilidade e das rotinas diárias. A tecnologia só ganha raízes quando quem lidera e quem executa domina o diagnóstico dos próprios problemas antes de pedir soluções à máquina.

Na aula Sextas Ímpares #143, de 15 de maio, falei sobre a armadilha comum em muitas empresas portuguesas: quase todas dizem usar IA no dia a dia, mas a maioria limita-se a redigir textos ou resumos genéricos, enquanto uma minoria usa vibe coding e automações mais avançadas para reduzir custos fixos e redesenhar a operação.

Capacitar equipas passa por focar primeiro nos porquês, não nas ferramentas. Quem já conhece a economia do negócio e sabe correlacionar métricas financeiras multiplica a produtividade ao receber ferramentas como Claude Code ou Codex. Quem não domina os fundamentos do negócio tende a limitar o uso dessas ferramentas a testes estéticos sem reflexo na faturação. Nas imersões presenciais que costumo dar, o formato é o de oficina prática: cada participante trabalha um desafio real da sua empresa e sai com uma versão inicial de uma ferramenta para testar depois no próprio negócio.

Como trabalhar comigo nesta área

Se precisas de uma equipa para implementar, tens os serviços da SpartAds. Se queres aprender e discutir o teu projeto comigo, conhece o Laboratório da IA e as formações disponíveis. Começa por explicar o que queres resolver e o que já tentaste; isso ajuda a perceber qual dos caminhos faz sentido.

Se procuras uma equipa para desenhar e implementar automações à medida, conhece os serviços de IA e automação da SpartAds. A equipa avalia os teus fluxos existentes e constrói integrações que devolvam previsibilidade à operação.

Se queres aprender a desenhar estes sistemas e acompanhar a evolução prática destas tecnologias com a minha orientação, inscreve-te no Laboratório da IA, onde conduzo duas mentorias por mês e revejo projetos práticos da comunidade.

Para convites de palestras ou formações executivas para a tua equipa, envia o contexto da tua proposta através da página de convites. A minha equipa avalia a disponibilidade e esclarece os objetivos antes de apresentar uma proposta. Para veres como articulo esta abordagem com geração de receitas, continua no artigo como transformar mais leads em clientes num negócio de serviços.

Um ensaio pequeno antes de entregar o processo à equipa

Antes de entregar uma automação à equipa, prepara um ensaio com poucos registos, situações diferentes e um responsável pela revisão. O ensaio deve mostrar o que o sistema faz quando tudo corre bem e quando falta informação. Guarda as decisões para que outra pessoa consiga perceber o resultado e repetir a verificação.

Imagina uma empresa de serviços que recebe pedidos pelo site. Este é um exemplo de desenho de processo, não um resultado de cliente: o formulário recolhe o pedido, uma regra confirma os campos necessários e a IA propõe uma categoria a partir da descrição. A equipa confirma a categoria antes de usar essa informação para decidir o próximo contacto.

Prepara três pedidos fictícios. No primeiro, o serviço está bem identificado; no segundo, a descrição é vaga; no terceiro, há dois pedidos diferentes na mesma mensagem. O sistema deve conseguir distinguir estes casos e mostrar quando não tem informação para continuar. Uma resposta convincente não resolve uma classificação errada.

Regista numa folha simples o pedido, a categoria esperada, a resposta recebida e o motivo da diferença. Se o modelo atribuir a mesma categoria a tudo, revê o contexto e os exemplos. Se faltar um campo, confirma que a automação assinala a falta em vez de o completar com uma suposição.

Depois testa a passagem à equipa. Quem recebe o pedido deve ver o texto original e conseguir corrigir a classificação, sem depender de quem construiu o fluxo. A mensagem interna precisa de indicar o próximo passo e o responsável. A notificação só ajuda se alguém souber o que fazer com ela.

Também deves ensaiar uma falha da integração. Interrompe a ligação num ambiente de teste e confirma se o pedido fica guardado, se surge um aviso e se a recuperação evita duplicar o contacto. Não faças este ensaio sobre pedidos reais sem um plano que proteja a operação.

Quando o processo estiver compreendido, aumenta o volume por etapas. Acompanha quantos casos precisam de correção, onde há atrasos e quanto custa executar o fluxo. Esses registos ajudam a decidir se vale a pena continuar, simplificar uma etapa ou manter parte do trabalho manual.