Quanto mais a palavra “IA” entra no vocabulário, menos ela explica. Desmistificar começa por separar as camadas antes de discutir a mágica.

TL;DR

Inteligência artificial não é uma peça única. Um modelo transforma entradas em saídas; uma automação percorre etapas predefinidas; um agente pode escolher próximos passos e usar ferramentas dentro de limites; um harness organiza contexto, memória, skills, fontes, permissões, pontos de aprovação e validações ao redor disso. As fronteiras não são universais, mas a distinção evita esperar compreensão humana de uma interface, autonomia de um modelo isolado ou segurança de um prompt bem escrito. A direção continua humana. O sistema serve para transformar essa direção em execução mais legível, governada e verificável.

“A IA fez.”

Essa frase pode até estar correta. Quase sempre está incompleta.

Depois de anos construindo software e, mais recentemente, orquestrando agentes, automações, memória, skills, subagentes, ferramentas, permissões e validações, eu a trato como um pedido de esclarecimento.

Qual parte do sistema fez exatamente o quê?

Foi um modelo gerando texto? Uma busca recuperando documentos? Um fluxo seguindo regras? Um agente escolhendo ferramentas? Um programa tradicional calculando o resultado? Uma pessoa aprovando a ação? Tudo isso junto?

Chamar cada uma dessas coisas de “IA” é como chamar motor, câmbio, motorista, estrada e regra de trânsito de “carro” e esperar que o mecânico descubra o resto pelo contexto.

Às vezes ele descobre.

Às vezes o orçamento também descobre você.

Desmistificar inteligência artificial não é fingir que tudo ficou simples. É separar as camadas o bastante para fazer perguntas melhores. Eu comecei a levar essa distinção mais a sério quando percebi que uma palavra ampla demais escondia decisões completamente diferentes: escolher um modelo, automatizar um processo, delegar ações ou governar uma operação não são variações do mesmo problema.

Primeiro: de qual IA estamos falando?

“Inteligência artificial” é um guarda-chuva enorme. Ele cobre técnicas, sistemas e aplicações muito diferentes: reconhecimento de imagens, previsão, recomendação, planejamento, processamento de linguagem, robótica e muito mais.

Neste texto, meu foco está nos sistemas generativos baseados em grandes modelos de linguagem e nas arquiteturas de agentes construídas ao redor deles. Não estou dizendo que toda IA funciona como um chatbot ou que todo sistema inteligente usa as mesmas técnicas.

A própria OCDE, ao explicar a definição atualizada de sistema de IA, reconhece que não existe uma linha vermelha simples separando IA de não IA. Sua definição descreve um sistema baseado em máquina que, a partir de entradas e objetivos explícitos ou implícitos, infere como gerar previsões, conteúdo, recomendações ou decisões capazes de influenciar ambientes físicos ou virtuais.

Essa formulação é útil por um motivo que costuma desaparecer na propaganda: ela fala em sistema, não numa entidade mágica.

E, dentro do sistema, o modelo é apenas um componente.

O mapa em uma página

As palavras variam entre empresas, artigos e ferramentas. A tabela abaixo não pretende encerrar a terminologia; ela oferece um mapa operacional para este blog.

Camada	O que faz	O que não garante
Modelo	Transforma uma entrada em uma saída a partir de padrões aprendidos	Fonte correta, objetivo adequado, memória durável ou acesso a sistemas externos
Automação	Executa uma sequência de etapas, regras e integrações	Julgamento sobre situações não previstas ou decisão responsável
Agente	Usa um modelo para escolher passos, consultar contexto e acionar ferramentas dentro de um objetivo	Autonomia ilimitada, confiabilidade ou permissão para agir em tudo
Harness	Organiza ambiente, contexto, memória, skills, ferramentas, fontes, permissões, checkpoints e validações	Verdade automática, risco zero ou boa direção humana

O ponto não é decorar os nomes.

É perceber que cada camada resolve um problema diferente — e cria um tipo diferente de risco.

Modelo: o motor não é a operação inteira

Um modelo recebe entradas e produz saídas.

No caso de um grande modelo de linguagem, isso envolve aprender regularidades a partir de grandes conjuntos de dados e gerar sequências compatíveis com o contexto recebido. A saída pode ser excelente, mediana, errada ou inventada com uma fluência que torna o erro mais difícil de notar.

O perfil de IA generativa do NIST usa o termo confabulação para saídas falsas ou erradas apresentadas com confiança. O documento explica que modelos generativos aproximam distribuições estatísticas dos dados de treinamento e que grandes modelos de linguagem predizem o próximo token. Isso pode produzir conteúdo correto e consistente; também pode produzir algo factualmente errado ou internamente contraditório.

Plausibilidade linguística não é prova.

O modelo não é automaticamente um banco de dados, um mecanismo de busca, uma política de acesso, um processo de negócio ou uma fonte da verdade.

Também não possui vontade própria. Quando parece perseguir um objetivo, existe uma combinação de treinamento, instruções, contexto, código e escolhas humanas produzindo esse comportamento.

É por isso que um prompt pode melhorar uma resposta sem transformar o modelo num sistema governado.

O prompt informa uma tarefa. Ele não cria sozinho controle de acesso, histórico confiável, aprovação humana, observabilidade, teste, rollback ou responsabilidade.

Um motor potente ainda precisa de todo o resto. A indústria levou décadas construindo essas camadas, como contei ao percorrer a evolução do mainframe aos agentes.

Automação: quando o caminho já pode ser desenhado

Automação é a execução de um processo por regras e integrações.

Ela pode usar IA, mas não precisa.

Um fluxo hipotético pode receber um documento, validar campos obrigatórios, consultar um cadastro, registrar o resultado e enviar uma notificação. Se as etapas e exceções relevantes são conhecidas, código tradicional ou uma ferramenta de automação de fluxos pode resolver o problema com mais previsibilidade, menor custo e menos espaço para improvisação.

Isso não é menos moderno.

É engenharia escolhendo a ferramenta proporcional ao problema.

Muita coisa vendida como “agente” é, na prática, uma automação com uma chamada de modelo no meio. Não há nada errado nisso. O erro começa quando o nome mais vistoso cria expectativas que a arquitetura não entrega.

Agente: autonomia delegada, não personalidade

Não existe uma definição universal de agente.

Uma referência de engenharia da Anthropic distingue fluxos de trabalho, nos quais modelos e ferramentas percorrem caminhos predefinidos, de agentes, nos quais o modelo dirige dinamicamente o processo e o uso de ferramentas. É uma taxonomia da própria empresa, não uma lei da computação, mas ajuda a localizar a mudança principal.

Num agente, o modelo não produz apenas uma resposta final. Ele pode observar o estado, escolher um próximo passo, acionar uma ferramenta, avaliar o resultado e continuar até concluir, falhar ou atingir um limite.

Isso não o transforma em trabalhador humano, parceiro afetivo ou dono da decisão.

A autonomia do agente foi delegada por alguém. Seu objetivo foi definido ou aceito por alguém. Suas ferramentas foram expostas por alguém. Suas permissões precisam ser limitadas por alguém. E suas ações materiais continuam exigindo responsabilidade humana e organizacional.

Quanto maior a autonomia, mais importante fica responder:

• o que o agente consegue ver?
• o que pode alterar?
• quando precisa pedir aprovação?
• como sua ação será registrada?
• qual validação separa tentativa de entrega?
• como interromper ou reverter quando algo sai do esperado?

Subagentes não mudam essa natureza. São uma forma de dividir contexto, especialidade e revisão entre instâncias ou papéis. Não formam uma equipe humana dentro da máquina.

Harness: o sistema que torna o agente operacional

É nessa camada que concentro boa parte do meu trabalho atual.

Um modelo melhor ajuda. Mas trocar de modelo não resolve, por conta própria, contexto espalhado, instruções contraditórias, memória sem origem, ferramenta sem permissão, decisão sem dono ou entrega sem validação.

Eu uso harness para nomear o sistema ao redor do agente. Sua função pode ser resumida em três compromissos:

• tornar o contexto legível, para que regras, fontes, histórico e objetivo não dependam de uma conversa perdida;
• tornar a ação governável, com ferramentas, permissões, pontos de aprovação, critérios de parada e responsáveis definidos;
• tornar o resultado verificável, com testes, registros e evidência suficiente para revisar, corrigir ou rejeitar a entrega.

Memória, skills, subagentes e ferramentas são formas de implementar esses compromissos. Não são personagens: memória é informação recuperável; skill é procedimento reutilizável; subagente é outra execução com contexto e função delimitados.

Um relato da OpenAI sobre harness engineering com Codex descreve a importância de tornar contexto, ferramentas, documentação e ciclos de feedback legíveis para agentes. É um caso específico da empresa, não uma receita universal. A distinção útil é esta: capacidade do modelo e qualidade do ambiente são problemas diferentes.

A base operacional que construí já consegue transformar critérios humanos em execução reutilizável, governada e verificável. Ela não é um modelo fundacional proprietário; é uma arquitetura que combina componentes e contratos de trabalho.

A melhor resposta não é a mais agradável

Existe outra camada que um diagrama técnico costuma esconder: o comportamento que escolhemos incentivar.

Eu não aperfeiçoo meus agentes para receber concordância mais elegante. Quero a melhor resposta verificável que o contexto e as fontes permitirem — inclusive quando ela aponta que minha pergunta está mal formulada, que falta evidência ou que estou defendendo uma hipótese cedo demais.

Um estudo sobre sycophancy em modelos de linguagem encontrou situações em que respostas alinhadas às crenças do usuário foram favorecidas mesmo quando isso competia com a correção. O trabalho não representa todos os modelos e contextos, mas sustenta um cuidado importante: agradabilidade não é uma métrica suficiente de qualidade.

Por isso, meus contratos pedem que o agente exponha incerteza, procure contrapontos, aponte pontos cegos e faça perguntas quando a ambiguidade pode mudar a execução.

Se ainda não está claro o que deve ser feito, eu não quero que um verbo no imperativo transforme confusão em ação.

A direção é minha.

O papel do sistema é ajudar a torná-la mais explícita, confrontá-la com a realidade e executá-la dentro de limites.

Esse critério é aprofundado em “A melhor resposta não é a que mais me agrada”.

Por que a confusão entre as camadas custa caro

Quando tudo recebe o mesmo nome, perguntas diferentes parecem ter a mesma resposta.

Uma empresa pode contratar um modelo esperando que ele conheça seus processos. Pode comprar uma plataforma de agentes quando uma automação simples resolveria. Pode liberar uma ferramenta crítica porque o chatbot respondeu bem durante uma demonstração. Pode chamar uma pasta de conversas de memória corporativa. Pode tratar um prompt como política de segurança.

O resultado nem sempre é uma catástrofe cinematográfica.

Às vezes é pior: uma coleção silenciosa de decisões difíceis de auditar, integrações frágeis, trabalho manual escondido e confiança que cresce mais rápido que a evidência.

Separar as camadas permite escolher o controle certo:

• modelo pede avaliação de qualidade, limites e comportamento;
• automação pede regras, tratamento de exceções e observabilidade;
• agente pede escopo, ferramentas, permissões e critérios de parada;
• harness pede governança, responsabilidade definida, memória, validação e manutenção contínua.

Não existe arquitetura que torne risco zero. Existe arquitetura que torna risco mais visível, limitado e tratável.

Governança não é um documento colocado no fim

Quando um sistema pode influenciar decisões ou agir sobre uma operação, governança precisa nascer junto com a arquitetura.

O AI Risk Management Framework 1.0 do NIST organiza a gestão de risco em funções como governar, mapear, medir e gerenciar. O framework é voluntário e amplo. Não certifica uma ferramenta específica, não garante conformidade e não substitui controles técnicos, jurídicos ou organizacionais do contexto.

Seu valor para esta conversa está em deslocar a pergunta.

Em vez de “qual IA vamos usar?”, começamos a perguntar:

• qual decisão ou processo está em jogo?
• quem pode ser afetado?
• quais dados e fontes sustentam a saída?
• que nível de erro é tolerável?
• onde a supervisão humana é obrigatória?
• como medir comportamento e qualidade depois do lançamento?
• quem pode interromper, corrigir e responder pelo sistema?

Governança não é o freio colocado depois da aceleração.

É parte da direção.

Quando não usar um agente

Desmistificar IA também significa admitir quando ela não é a melhor solução.

Eu começaria por algo mais simples quando:

• as regras são estáveis e podem ser codificadas diretamente;
• o erro aceitável é próximo de zero e não existe validação segura;
• os dados necessários não podem ser expostos ao modelo ou à plataforma;
• não há dono para aprovar ações, monitorar resultados e responder por falhas;
• o custo de imprevisibilidade supera o ganho de flexibilidade;
• uma pessoa consegue resolver o caso raro melhor que um sistema permanente.

Agentes são úteis quando existe variabilidade real, contexto suficiente, ferramentas bem delimitadas e critérios de avaliação. Fora disso, adicionar autonomia pode ser apenas uma maneira cara de tornar o erro mais criativo.

O que isso tem a ver com a i-9.ai

Essa separação de camadas já orienta o que consigo entregar pela i-9.ai.

Não começar pela ferramenta da semana. Começar pela operação.

Entender o problema, os dados, as decisões, as pessoas e os riscos. Descobrir se a resposta pede software, automação, um modelo, um agente, um harness inteiro — ou nenhuma dessas coisas. Só então desenhar uma solução customizada e governada.

A base é reutilizável, e algumas automações estão maduras o bastante para serem praticamente replicadas. Isso não elimina a adaptação: integrações, permissões, dados, riscos e processos continuam pertencendo ao contexto de cada cliente.

Sempre que o problema permite, minha preferência é por código aberto, infraestrutura privada e soberania sobre dados, políticas e operação. Não é dogma nem promessa de isolamento absoluto. Dependências externas úteis precisam ser avaliadas, declaradas e governadas.

O princípio da entrega permanece: tecnologia deve ampliar capacidade sem esconder dependência, incerteza ou responsabilidade. Se essa forma de pensar se parece com o que sua empresa precisa, entre em contato. A conversa começa pela operação, não pela ferramenta da semana.

Sete perguntas antes de aceitar “vamos colocar IA”

Quando a próxima conversa começar com essa frase, tente devolver sete perguntas:

1. Qual resultado concreto precisa mudar?
2. Estamos pedindo uma resposta ou autorizando uma ação?
3. Quais dados, fontes e contexto o sistema poderá usar?
4. O caminho pode ser automatizado ou exige escolhas dinâmicas?
5. Quais ferramentas e permissões serão realmente necessárias?
6. Quem verifica, aprova e responde pelas decisões materiais?
7. Como detectar falha, interromper a execução e voltar a um estado seguro?

Se ninguém consegue responder, o projeto ainda não está pronto para acelerar.

Talvez esteja pronto apenas para pensar melhor.

E isso já é um começo.

Desmistificar IA não diminui a tecnologia. Faz o contrário: retira dela a obrigação de sustentar uma fantasia e permite enxergar onde a capacidade realmente existe.

Quando a mágica sai de cena, entram arquitetura, contexto, critério, limite e responsabilidade.

É aí que a inteligência artificial começa a ficar útil.

Continue lendo

• A melhor resposta não é a que mais me agrada: como transformar critério anti-bajulação em contexto, permissões, checkpoints e validações.
• Evolução da tecnologia: do mainframe ao trocadilho infame em tempo real: a linha histórica que tornou possível conversar com sistemas capazes de usar contexto e ferramentas.
• A previsibilidade sedutora da IA: por que uma interface fluida e personalizada continua diferente de reciprocidade humana.

Referências e limites de uso

As fontes abaixo sustentam definições, distinções ou práticas específicas. Nenhuma delas prova que uma arquitetura concreta será segura, eficaz ou adequada sem avaliação do contexto.

• OCDE.AI, “What is AI? Can You Make a Clear Distinction Between AI and Non-AI Systems?” (2024) (acesso em 26 ago. 2026): explica a definição atualizada de sistema de IA e distingue modelo de sistema; reconhece que não existe uma fronteira simples e universal.
• Anthropic, “Building Effective Agents” (2024) (acesso em 26 ago. 2026): apresenta a distinção usada pela empresa entre workflows predefinidos e agentes que dirigem dinamicamente o uso de ferramentas; não é padronização universal.
• Sharma et al., “Towards Understanding Sycophancy in Language Models” (2023): investiga sycophancy em cinco assistentes e o papel de dados de preferência; não representa todas as versões, arquiteturas ou situações de uso.
• NIST, “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile” (2024): define e contextualiza riscos de confabulação em IA generativa; não implica que toda saída seja falsa nem mede um modelo específico deste artigo.
• NIST, “Artificial Intelligence Risk Management Framework 1.0” (2023): framework voluntário para governar, mapear, medir e gerenciar riscos de IA; não é certificação nem garantia de conformidade ou segurança.
• OpenAI, “Harness Engineering: Leveraging Codex in an Agent-First World” (2026) (acesso em 26 ago. 2026): relato de engenharia sobre contexto legível, documentação, ferramentas e ciclos de feedback num projeto específico com Codex; não demonstra adequação a toda organização.