Esta pergunta tem uma resposta curta, e aí está a armadilha. A lista de ferramentas é fácil de recitar e não diz quase nada sobre a qualidade do que será construído. Damos a nossa mesmo assim, porque um prestador que se recusa a dá la tem um problema.

O que utilizamos

  • Modelos de linguagem. Sobretudo os da Anthropic e da OpenAI, escolhidos tarefa a tarefa. Uma classificação de grande volume não pede o mesmo modelo que uma redação. A escolha é reversível: o código nunca pressupõe um fornecedor único.
  • Interfaces de programação. As das suas ferramentas de negócio, as das plataformas publicitárias, as das mensagens e dos sistemas de pagamento. É aí que está o verdadeiro trabalho de integração.
  • Base de dados. Uma base relacional com regras de acesso por linha, que continua a ser a fonte de verdade. Os modelos leem e escrevem através dela, nunca ao lado.
  • Execução. Funções distribuídas na periferia da rede, tarefas agendadas e filas de espera para tudo o que seja longo, caro ou suscetível de falhar.
  • Bases de conhecimento. Os seus documentos divididos, indexados e citados, para que o modelo responda a partir da sua matéria e não da sua memória.
  • Permissões e autenticação. Uma identidade por utilizador, papéis e habilitações verificadas no servidor. Nunca só no navegador.
  • Registo e supervisão. Cada ação automatizada deixa um rasto legível, com o seu custo, o seu resultado e o seu autor. Nos casos anómalos saem alertas.

Porque a lista não é a resposta

Dois prestadores podem citar exatamente as mesmas tecnologias e entregar duas coisas radicalmente diferentes. O que os separa cabe em cinco perguntas, a fazer logo a seguir:

  • O que acontece quando uma chamada falha? Nova tentativa, espera progressiva, fila, abandono com alerta: é preciso uma resposta precisa, diferente conforme os casos.
  • Quem tem o direito de desencadear o quê? Uma automatização que corre com uma conta todo poderosa é um incidente à espera.
  • Como se sabe o que aconteceu? Sem um registo consultável não há diagnóstico possível, logo não há correção.
  • Quanto custa a utilização? O custo dos modelos mede se por chamada. Uma arquitetura que não o mede não o controla.
  • O que permanece determinista? Tudo o que puder ser uma regra deve continuar a ser uma regra. O modelo só intervém onde é preciso julgamento.
O modelo é o componente mais visível de uma automatização. Raramente é o que decide o seu sucesso.

Sobre as plataformas sem código

Plataformas como n8n, Make ou Zapier são excelentes ferramentas e nada temos contra elas. Servem perfeitamente encadeamentos simples, de pouco volume, sem lógica condicional profunda. Tornam se caras e frágeis quando o processo se complica, quando o volume sobe, ou quando é preciso uma recuperação fina após erro.

O verdadeiro assunto não é portanto «código contra sem código», mas: em que momento se muda de veículo, e quem lho dirá com honestidade.

Um detalhe que muda tudo: em que conta corre a IA

Quando pilotamos as suas automatizações, as chamadas aos modelos correm nos seus próprios acessos, na sua conta, na sua fatura. Vê o consumo, pode limitá lo e pode cortá lo. Este ponto parece administrativo: na realidade determina quem controla a ferramenta, e liga se diretamente à questão da propriedade.

Para ver como estas peças se montam na prática, a página Orquestrador de IA descreve o trabalho de pilotagem, e este artigo levanta o capô.