Guias, comparações e novidades sobre ferramentas de IA

O primeiro obstáculo ao colocar um agente de IA em trabalho real é "em qual framework construí-lo". Da ótica do desenvolvedor e de quem seleciona a tecnologia, este artigo compara seis frameworks principais — LangGraph, CrewAI, AutoGen (integrado ao Microsoft Agent Framework, GA em abril de 2026), OpenAI Agents SDK, Google ADK e Claude Agent SDK — por abordagem de orquestração (grafo dirigido / crew baseada em papéis / GroupChat conversacional / handoffs / árvore hierárquica / laço autônomo de ferramentas), linguagem, curva de aprendizado, controle, maturidade em produção, custo de tokens e caso de uso ideal. A ressalva central: o framework "mais rápido de prototipar" (CrewAI) pode ser o mais caro em produção — cerca de 3× os tokens (41k contra 18,5k do LangGraph em um benchmark) e não determinístico, o que o torna inadequado para finanças e saúde. Também explica como 2026 trouxe interoperabilidade via MCP (ferramentas) e A2A (agente a agente), de modo que agentes de frameworks diferentes agora trabalham juntos e o lock-in desapareceu. Inclui um guia de seleção por caso de uso e FAQ.

IA ou humano, quem é melhor em segurança? A resposta mudou muito em 2025–2026. O Big Sleep, do Google, barrou um zero-day real (o CVE-2025-6965 do SQLite) antes do abuso, e o pentester de IA autônomo XBOW chegou ao 1º lugar do ranking dos EUA na HackerOne. Por outro lado, 45% do código gerado por IA traz vulnerabilidades (cerca de 2,74 vezes mais que o humano) e ocorreu o primeiro ciberataque de larga escala liderado por IA, com abuso do Claude (80–90% do ataque executado de forma autônoma). Com base em fontes primárias de Google, Anthropic, DARPA e Veracode, este artigo compara, em uma tabela por tarefa, a IA — que domina em velocidade, escala e cobertura — e o humano, superior em lógica de negócio, encadeamento de ataque e decisão final. Mostra ainda que a IA é uma faca de dois gumes com tríplice face — "fonte geradora de vulnerabilidades, ferramenta de ataque e o defensor mais forte" — e conclui, para profissionais e gestores, que o vencedor é a divisão de papéis "humano × IA" (modelo centauro) somada ao human-in-the-loop.

O Ollama é a ferramenta de referência para começar com LLMs locais: ele cuida de quase toda a configuração trabalhosa para que você baixe um modelo e converse com um único comando. Este guia para iniciantes percorre tudo do começo ao fim — instalação no Windows, Mac e Linux, os comandos essenciais, como obter e escolher modelos pelo tamanho e pela VRAM, usar uma GUI como o Open WebUI, integrar a API local (inclusive a compatível com OpenAI) aos seus próprios apps, personalizar com Modelfile e variáveis de ambiente, além de soluções para os problemas mais comuns.

Um guia prático para escolher qual modelo de LLM local instalar em 2026, organizado por desenvolvedor, país de origem, caso de uso, tamanho e licença. Cobre as principais famílias (Qwen, Llama, Gemma, DeepSeek, Mistral, Phi, GLM) e destaca modelos focados em português e regionais — Sabiá e Tucano (Brasil), Albertina e Gervásio (Portugal) —, além de modelos multilíngues fortes bem ajustados ao português, com recomendações por VRAM e alertas de licenciamento para uso comercial.

Quer rodar um LLM local mas não sabe se o seu PC dá conta? Cerca de 90% da especificação se resume à VRAM (a memória da GPU). Este guia traz uma tabela rápida de VRAM por tamanho de modelo, uma fórmula simples, a armadilha do cache KV que cresce com o contexto, velocidades realistas por GPU e Mac, e três níveis de configuração por orçamento. Com o jargão ao mínimo, até iniciantes descobrem qual hardware comprar.

Um LLM local que você roda no próprio PC ou LLMs em nuvem como Claude, ChatGPT e Gemini — ambos são "LLMs", mas diferem em desempenho, custo, privacidade e esforço. Este artigo coloca tudo lado a lado em uma única comparação e mostra com honestidade até onde a mal compreendida "diferença de desempenho" diminuiu em 2026, hoje desprezível para muitos casos de uso. Em seguida, ele guia você pela escolha na ordem confidencialidade → qualidade → volume, com um guia de decisão prático. Para a maioria das pessoas, a resposta é o híbrido: o local para o trabalho confidencial e rotineiro, a nuvem para as partes mais difíceis.

Quanto mais a IA generativa se entranha no trabalho, mais pesa a pergunta "e se amanhã essa IA sumir?". Em junho de 2026, um modelo de ponta foi suspenso três dias após o lançamento e foi reativado 19 dias depois (1 de julho de 2026). Este artigo explica o que é o risco de dependência de IA, as seis formas pelas quais uma IA pode "sumir" e os passos concretos de preparo — para usuários individuais e para sistemas em produção. A ideia central é proteger por design, não por previsão: tenha uma alternativa pronta, mantenha dados e prompts do seu lado e desenhe a IA como uma peça removível, com gateway de LLM, cadeia de fallback e um manual de recuperação.

As regras de permissão do Claude Code definem, no settings.json, quais ferramentas, comandos, arquivos e domínios são executados sem perguntar, exigem confirmação ou ficam proibidos. Veja a sintaxe allow/ask/deny, a hierarquia do settings.json e receitas práticas para automatizar o seguro e bloquear o perigoso.

O modo de permissão decide com que frequência o Claude pausa para pedir aprovação antes de editar arquivos ou executar comandos. Este guia explica os 5 modos — Solicitar permissões, Aceitar edições, Modo de planejamento, Modo automático e Ignorar permissões —, como alternar com Shift+Tab e como escolher cada um com segurança.

O controle de esforço do Claude Code decide quanto raciocínio e quantos tokens a IA aplica em cada resposta. Veja os 5 níveis da API (low–max), por que “Extra” é xhigh e não o topo, o que é o Ultracode e como definir tudo com /effort.

As avaliações de agentes são o processo de medir sistematicamente se um agente — que usa ferramentas e dá várias etapas para atingir um objetivo — consegue de fato cumprir suas tarefas. Elas são uma evolução das avaliações de LLM, expandindo o alvo de "uma saída" para "uma sequência de ações". Como um agente planeja, chama ferramentas e atualiza o estado, a saída final sozinha não basta; o Google observa que é preciso entender o "porquê" por trás das ações de um agente e divide a avaliação em resposta final e trajectory. As cinco dimensões são: resultado (sucesso da tarefa, julgado pelo estado final — se existe uma reserva no DB, não a fala "fiz a reserva"), trajectory (etapas razoáveis, ferramentas certas na ordem certa), correção do uso de ferramentas (ferramenta e argumentos certos, verificando nomes e tipos de funções), eficiência (etapas, tokens, custo, latência — muitas vezes sinais de observabilidade trazidos para a avaliação) e qualidade da resposta final (via LLM-as-judge ou uma rubrica). Os avaliadores são código (rápido/barato/reproduzível, mas frágil), LLM-as-judge (flexível, mas não determinístico e precisa de calibração) e humano (padrão-ouro, mas caro — evite se possível). A Anthropic recomenda pontuar o resultado, não o caminho: a correspondência mecânica de trajectory é "rígida e frágil demais" porque os agentes encontram alternativas válidas, enquanto Google e Microsoft oferecem métricas de correspondência de trajectory para diagnosticar falhas. As armadilhas exclusivas são o não determinismo (pass^k), os erros que se acumulam (p^t), o reward hacking (o braço robótico da DeepMind fingindo agarrar) e os conjuntos de avaliação obsoletos ou contaminados. A jogada prática, segundo a Anthropic: transformar 20 a 50 falhas de produção em casos de teste, executar pontuação automatizada no CI, separar avaliações de capacidade e de regressão e escrevê-las cedo. Benchmarks como SWE-bench, tau-bench, WebArena, GAIA, OSWorld e BFCL são referências úteis (as pontuações variam por versão, então não as tome ao pé da letra). Com base em informações oficiais, com as incertezas sinalizadas.

Os hooks do Claude Code são comandos de shell definidos pelo usuário que rodam automaticamente em pontos específicos do ciclo de vida do Claude Code, tornando o "isto precisa sempre acontecer" real e determinístico sem depender do julgamento do LLM. Os eventos clássicos são nove — SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, Notification, Stop, SubagentStop, SessionEnd, PreCompact — dos quais PreToolUse e outros podem bloquear (impedindo edições em arquivos protegidos ou comandos perigosos). Você os configura em settings.json sob a chave "hooks" como nome do evento -> matcher -> type + command. O contrato de E/S: um hook recebe JSON na stdin (session_id, tool_input, etc.) e retorna via código de saída 0 (sucesso) / 2 (bloquear, com a stderr passada de volta ao Claude) ou JSON estruturado (continue, decision:block, permissionDecision: deny/allow/ask). O princípio-chave é "os hooks podem apertar, mas não afrouxar restrições" (deny sempre vence, bloqueia até sob bypassPermissions). Casos de uso clássicos: formatar após edições (PostToolUse + Edit|Write), proteger arquivos críticos, bloquear comandos perigosos, reinjetar contexto (SessionStart), notificações/log de auditoria e testar antes de parar (Stop). Sobre segurança, os hooks executam comandos de shell arbitrários com os seus privilégios, então configure apenas os confiáveis e valide/coloque entre aspas as entradas; a configuração dos hooks é capturada no início da sessão (um recurso de segurança), então alterações no meio da sessão não se aplicam. Com base na documentação oficial, ancorado nos nove eventos clássicos e no contrato de E/S.