Glossário
Definições dos conceitos usados na transformação em IA.
Maturidade em IA
AI-Assisted – A IA é uma ferramenta pessoal; nada estrutural muda se ela desaparecer. Veja o framework de referência.
AI-Integrated – A IA está integrada aos fluxos de trabalho; os papéis passam de fazer para dirigir. Veja o framework de referência.
AI-Native – O design do trabalho pressupõe a IA como recurso de primeira classe; papéis definidos por julgamento, não execução. Veja o framework de referência.
AI-Supportive – A liderança endossa a IA pessoalmente sem impulsionar a adoção organizacional. Veja o framework de referência.
AI-Operational – A liderança define expectativas baseadas em papéis e financia a automação antes de contratar. Veja o framework de referência.
AI-Strategic – A liderança redesenha a organização em torno da IA e faz da literacia em IA uma condição de liderança. Veja o framework de referência.
Não exposto (Tier 0) – A IA não faz parte do trabalho. Sem experimentação, sem consciência das capacidades. Veja o framework de referência.
IA-curioso (Tier 0.5) – Já tentou a IA mas ela não mudou como o trabalho é feito. A lacuna para o Tier 1 não é conhecimento, é o hábito de recorrer à IA quando o trabalho começa. Veja o framework de referência.
IA-consciente (Tier 1) – O indivíduo usa IA como ferramenta pessoal sem mudar os fluxos de trabalho. Veja o framework de referência.
IA-construtor (Tier 1.5) – Projetando e testando ativamente fluxos de trabalho de IA. Construindo prompts, iterando, experimentando. A fase de construção entre o uso ad hoc e os fluxos de trabalho estabelecidos. É aqui que a maioria das pessoas emperra. Veja o framework de referência.
IA-aumentado (Tier 2) – O indivíduo integra a IA em fluxos de trabalho recorrentes de forma sistemática. Veja o framework de referência.
IA-avançado (Tier 2.5) – Construindo sistemas onde a IA trata a maior parte da execução. Múltiplos processos redesenhados. O título do papel não mudou mas o trabalho interno mudou. Veja o framework de referência.
IA-nativo (Tier 3) – Papel redesenhado em torno de julgamento e direção. A pessoa prevê para onde o limite humano-agente vai se mover e aloca atenção onde ela cria mais valor. Veja o framework de referência.
Engenharia de IA
Produção autônoma (Rung 5)
Modelo de engenharia onde a spec entra e o software sai sem intervenção humana no código. O humano define arquitetura, restrições e cenários; a IA produz, testa e itera o código. Também conhecido como dark factory. Veja o Lab de IA.
Codificação assistida (Rung 0)
Modo de desenvolvimento onde o humano codifica e a IA sugere completações. O nível mais baixo de assistência de IA em engenharia de software.
Desenvolvimento não interativo
Modo de trabalho onde especificações e cenários conduzem agentes autônomos. O humano não codifica e não conversa com o agente durante a execução. Veja o Lab de IA.
Cenários
Jornadas de usuário de ponta a ponta que descrevem o comportamento esperado da perspectiva do usuário. Preferidos aos testes unitários porque são mais difíceis de contornar por agentes. Veja o Lab de IA.
Métrica de satisfação
Abordagem de avaliação que mede a fração de trajetórias em todos os cenários que satisfazem o usuário, em vez de um resultado binário verde/vermelho. Veja o Lab de IA.
Ingenuidade deliberada
A postura de remover as convenções tradicionais de desenvolvimento e perguntar sistematicamente: "Por que estou fazendo isso? O modelo deveria estar fazendo isso." Veja o Lab de IA.
Greenfield
Um projeto iniciado do zero, sem código existente. O terreno mais natural para o desenvolvimento não interativo. Veja o Lab de IA.
Brownfield
Um projeto com código e hábitos existentes, em transição para o modelo de produção autônoma. Mais difícil do que greenfield, mas mais impactante. Veja o Lab de IA.
Habilidades em IA
Literacia em IA – Uso estruturado de ferramentas de IA e capacidade de distinguir uso ad hoc de integração em fluxos de trabalho. Veja o guia do colaborador.
Criação de prompts – Instruções claras, formato especificado, exemplos, ambiguidade resolvida. Veja os padrões de execução.
Engenharia de contexto – Arquivo de contexto estruturado carregado antes das tarefas de IA. Veja os padrões de execução.
Engenharia de intenção – Hierarquia de objetivos definida, regras de trade-off e condições de escalada. Veja os padrões de execução.
Engenharia de especificação – Toda tarefa não trivial tem uma especificação escrita completa construída a partir de cinco primitivos. Veja os padrões de execução e o Guia de Especificação para exemplos práticos.
Especificação – Um documento que define um problema com precisão suficiente para que um agente o resolva autonomamente. Veja os padrões de execução e o Guia de Especificação.
Declarações de problema auto-suficientes – Problema declarado com contexto suficiente para ser solucionável sem informações adicionais. Veja os padrões de execução.
Critérios de aceitação – Como é o "pronto", verificável por um observador independente. Veja os padrões de execução.
Arquitetura de restrições – Quatro categorias por tarefa: Deve, Não Deve, Prefira, Escale. Veja os padrões de execução.
Decomposição – Tarefas divididas em componentes independentemente executáveis, testáveis e integráveis. Veja os padrões de execução.
Design de avaliação – Casos de teste com outputs conhecidos e bons para validar e detectar regressões. Veja os padrões de execução.
Design de costuras
A prática de estruturar o trabalho para que as transições entre fases humanas e de agente sejam limpas, verificáveis e recuperáveis. Uma boa costura define o artefato de handoff, permite verificar o output do agente no ponto de transição e possibilita intervenção sem recomeçar do zero. As costuras mudam conforme as capacidades evoluem. Veja o guia do colaborador.
Economia da Transformação
Migração de valor
A tecnologia redistribui valor para a camada mais escassa. Na transformação em IA, o valor deixa a execução (commodity) e se concentra em julgamento, enquadramento e propriedade do risco (premium). Veja a visão.
As 5 funções humanas
Direção, Julgamento, Gosto, Relacionamento, Responsabilidade. As funções que permanecem insubstituíveis em uma organização IA-nativa. Veja a visão.
Evolução dos Papéis
Convergência – Múltiplos papéis se fundem porque a IA remove a sobrecarga de coordenação que justificava separá-los. O papel convergido retém a superfície de julgamento combinada. Veja Evolução dos Papéis.
Especialização – Um papel se estreita para seu núcleo humano irredutível à medida que a IA absorve a camada de rotina. O papel fica mais nítido, não menor. Veja Evolução dos Papéis.
Elevação – Os humanos passam de produzir artefatos para especificá-los e avaliá-los. Mapeia diretamente para a Regra de Tradução Universal do framework. Veja Evolução dos Papéis.
Absorção – As responsabilidades de um papel são absorvidas por papéis adjacentes ou sistemas. As responsabilidades se redistribuem; o papel se contrai ou desaparece. Veja Evolução dos Papéis.
Emergência – Papéis estruturalmente novos surgem da estrutura organizacional IA-nativa. Nomeados por sua responsabilidade, não pela tecnologia. Veja Evolução dos Papéis.
Matriz de Decisão de Papéis – Uma ferramenta estruturada que mapeia condições observáveis para o padrão de evolução mais provável e a ação recomendada. Veja Evolução dos Papéis.
Adoção e Transição
Curva J de adoção
A queda de produtividade previsível durante a adoção de IA. A produtividade cai antes de subir. As organizações que sobem são as que redesenham seus fluxos de trabalho em torno das capacidades da IA. Veja o guia do gestor.
Briefing de transição
Um documento estruturado entregue por um colaborador que descreve seu papel atual, visão AI-first, lacuna, sistemas a construir, métricas e plano de 30/60/90. Veja o guia do colaborador.
Clínicas de IA
Sessões regulares (semanais ou quinzenais) onde a equipe compartilha descobertas, bloqueadores e fluxos de trabalho. Formato curto (30 min). O objetivo é aprendizado entre pares. Veja o guia do gestor.
Parede dos seis meses
Padrão de falha onde projetos conduzidos por IA sem forte envolvimento humano (specs, cenários, arquitetura) acumulam dívida estrutural que explode por volta dos seis meses. Os cenários são a principal defesa. Veja o Lab de IA.
Decaimento de calibração
As habilidades em IA expiram conforme as capacidades evoluem. Uma pessoa que calibrou sua percepção do limite humano-agente há seis meses está agora ou confiando demais ou subutilizando os modelos atuais. O antídoto é a densidade de feedback: ciclos frequentes de delegar-avaliar-ajustar com modelos atuais, não treinamento pontual. Veja o guia do gestor.
Custo Cognitivo
Curva em J cognitiva
A contrapartida em energia mental da curva J de produtividade. A carga cognitiva sobe acentuadamente durante a transição Tier 1→2 (aprender a especificar, avaliar output não confiável, manter a carga de trabalho normal) e cai novamente quando os fluxos de trabalho se estabilizam no Tier 2. O esgotamento se concentra na transição, não no estado final. Veja Custo Cognitivo.
Sobrecarga cognitiva ("brain fry")
Fadiga mental gerada pela supervisão de IA que ultrapassa a capacidade cognitiva. Sintomas: névoa mental, decisões mais lentas, taxas de erro subindo. O estudo da BCG/UC Riverside constatou que os ganhos de produtividade se invertem após três ferramentas de IA simultâneas. Veja Custo Cognitivo.
Fadiga de decisão
Esgotamento pelo volume de micro-decisões que a IA introduz. Cada output de IA é uma decisão (bom o suficiente, editar, gerar novamente, confiar, verificar) e o volume degrada a qualidade das decisões que realmente importam. Veja Custo Cognitivo.
Fadiga de vigilância
Esgotamento pelo monitoramento sustentado de sistemas de IA que estão geralmente corretos. Estruturalmente similar à complacência com automação na aviação: a atenção deriva porque o sistema funciona bem na maior parte do tempo, e os erros têm aparência plausível. Veja Custo Cognitivo.
Intensificação do trabalho
O padrão em que a IA expande o escopo em vez de reduzi-lo. Três mecanismos: expansão de tarefas (as pessoas assumem trabalhos que antes não teriam tentado), limites difusos (as ferramentas de IA parecem informais, o trabalho vaza), e multitarefa (a IA gera em paralelo enquanto os humanos monitoram). Veja Custo Cognitivo.
Inflação da carga de trabalho
A tentação organizacional de aumentar as cotas de output proporcionalmente à velocidade habilitada pela IA. A capacidade de produção escala com a IA; a capacidade de julgamento não. Dobrar as cotas de output porque os rascunhos saem mais rápido é como as pessoas mais engajadas entram em burnout. Veja Custo Cognitivo.
Ansiedade relacionada à IA
Estresse antecipatório impulsionado pela incerteza sobre segurança no emprego, relevância das habilidades e trajetória de carreira. Distinta do "brain fry": atinge pessoas que temem a IA, inclusive as que ainda não começaram a usá-la. Veja Custo Cognitivo.
Ruptura de identidade
Perda de identidade profissional quando a IA executa habilidades que definiam a autoimagem. Mesmo quando os papéis melhoram objetivamente, os trabalhadores relatam sentimentos de obsolescência, perda de propósito e redução da autoestima. Veja Custo Cognitivo.
Desamparo aprendido
O padrão de retirada quando os sistemas de IA tomam decisões que os trabalhadores não entendem, não controlam ou não conseguem anular. As pessoas param de pensar criticamente sobre o output de IA e deferem mesmo quando discordam. O padrão mais perigoso para a transformação porque parece conformidade. Veja Custo Cognitivo.
Fadiga de transformação
Esgotamento acumulado pela mudança constante (novas ferramentas, novos fluxos de trabalho, novas expectativas) sobre a carga de trabalho normal. Não específica à IA mas agravada por ela. Uma resposta racional à demanda cognitiva sustentada sem recuperação suficiente. Veja Custo Cognitivo.
Maturidade do código
Níveis de maturidade do código
Um modelo de cinco níveis para avaliar se uma base de código suporta o desenvolvimento IA-nativo: Opaco (N0), Instrumentado (N1), Validado (N2), Legível (N3), Especificado (N4), Governado por cenários (N5). Cada nível é definido pelo mecanismo de feedback que ele adiciona. O nível de maturidade de uma base de código é o teto do Rung de engenharia que pode operar nele de forma confiável. Veja Maturidade do código.
Grade de maturidade do código (Codebase Readiness Grid)
O diagnóstico de nove dimensões no núcleo do modelo de Maturidade do código. Cada dimensão é pontuada de 1 a 5 em relação à sua própria rubrica. A Grade é um vetor, não um escalar: nunca é resumida com uma média. O teto (pontuação mais baixa) define o nível de maturidade; as dimensões bloqueadoras (D1, D2, D5) têm prioridade sobre as restritivas. Uma skill de código aberto para Claude Code executa a Grade em qualquer repositório.
Harness
A infraestrutura que envolve um agente de codificação IA e que restringe e valida seu output. Duas partes: guias (feedforward: tipos, convenções, documentação, arquitetura) e sensores (feedback: testes, CI, observabilidade). Definido por Fowler como "Agent = Model + Harness." Em bases de código brownfield, construir o harness é o ponto de alavancagem, não escolher um modelo melhor. Veja Maturidade do código.
Ambient affordances
Propriedades estruturais de uma base de código que a tornam legível para um agente de IA sem instrução explícita: tipagem forte, fronteiras de módulo claras, nomenclatura consistente, frameworks estabelecidos, fronteiras de dependência explícitas. Sua ausência força os agentes a inventar estrutura ou injetar inconsistência. Veja Maturidade do código.
Dimensões bloqueadoras
As três dimensões de Maturidade do código cujas pontuações baixas comprometem fundamentalmente o trabalho do agente e não podem ser compensadas por pontuações altas em outros lugares: cobertura de testes e latência de feedback (D1), rigor de tipos (D2) e diretividade de API (D5). Uma base de código pontuando 1 a 2 em qualquer uma dessas não é salva por pontuar 5 em todo o resto. Veja Maturidade do código.
Dimensões restritivas
As seis dimensões de Maturidade do código que degradam a qualidade do output do agente quando têm pontuação baixa, mas não bloqueiam o trabalho do agente completamente: tamanho de arquivo e legibilidade de contexto, clareza das fronteiras de módulo, intenção documentada, observabilidade, simplicidade de desenvolvimento e deploy, e atualidade de dependências e runtime. Pontuações baixas aqui significam mais revisão humana por mudança e mais limpeza, mas os agentes ainda conseguem produzir valor confiável. Veja Maturidade do código. Veja Maturidade do código.
Estratégia brownfield
Os quatro modos brownfield
Remediar no lugar, migração strangler-fig, reconstrução completa, isolar e contornar. Cada um se adequa a uma combinação diferente de solidez arquitetural, clareza de costuras, restrições de continuidade de negócio, capacidade de equipe e valor restante no legado. Escolher o modo errado é caro. Veja Estratégia de engenharia brownfield.
Isolar e contornar
Um modo brownfield onde o legado é congelado em modo de manutenção e novo valor é entregue como apps autônomos prontos para o Nível 5 ao lado. A escolha certa quando o custo de remediação excede o valor restante no legado. Compra tempo mas não resolve o problema subjacente: eventualmente algo força a decisão de substituição. Veja Estratégia de engenharia brownfield.
Pesquisa, Revisão, Reconstrução
Uma metodologia em fases para modernização brownfield assistida por IA (Fowler/EPAM): Pesquisa (a IA reconstrói a intenção a partir do código existente), Revisão (especialistas de domínio validam o mapa de intenção), Reconstrução (a IA gera código de substituição com ambiguidade mínima). Pular Pesquisa e Revisão produz output errado mais rápido. A revisão humana é o gargalo de throughput, não a geração de IA. Veja Estratégia de engenharia brownfield.
Spec-from-code
A inversão brownfield do desenvolvimento guiado por spec. As specs precedem o código no greenfield; no brownfield, as specs precisam ser extraídas por engenharia reversa do código existente antes que o novo trabalho spec-first possa ser retomado. Extrair a especificação implícita é o trabalho mais difícil e mais humano da transição: os agentes podem documentar o que o sistema faz, apenas humanos conseguem distinguir comportamento intencional de acidente histórico. Veja Estratégia de engenharia brownfield.
Migração strangler-fig
O padrão de substituir um sistema legado peça por peça, com as novas partes rodando ao lado das antigas por trás de uma fachada, até que o sistema antigo possa ser aposentado. A identificação de costuras (encontrar onde as responsabilidades podem ser extraídas de forma limpa) é a habilidade crítica. A IA torna a substituição mais barata mas não elimina a necessidade de encontrar as costuras. Veja Estratégia de engenharia brownfield e o Strangler Fig Pattern original de Martin Fowler.
Technical Debt Quadrant
A categorização em quatro vias da dívida técnica de Fowler por intenção (deliberada vs. inadvertida) e disciplina (prudente vs. imprudente). O quadrante orienta a estratégia de remediação: a dívida prudente-inadvertida é frequentemente remediável; a dívida imprudente-inadvertida é tipicamente candidata à reconstrução porque a estrutura reflete ignorância que o conhecimento posterior não consegue desfazer no lugar. Veja Estratégia de engenharia brownfield.
Identificação de costuras
A prática de encontrar lugares em uma base de código legada onde as responsabilidades podem ser extraídas de forma limpa para migração strangler-fig. Popularizada por Michael Feathers em Working Effectively with Legacy Code. A habilidade crítica que determina se uma abordagem strangler-fig produz um sistema mais limpo ou dois sistemas acoplados.
Técnicas Black Box to Blueprint
Cinco técnicas de engenharia reversa (Fowler) para sistemas legados opacos: reconstrução da camada de UI, change data capture, inferência de lógica de servidor, arqueologia binária e enriquecimento progressivo multi-passagem. Duas disciplinas inegociáveis: triangulação (confirme toda hipótese em duas fontes independentes) e rastreamento de linhagem (registre a evidência em que cada afirmação se baseia). Veja Estratégia de engenharia brownfield.
Realidade operacional em T3 / R5
Unidade operacional de cinco estágios
A unidade operacional recorrente no Tier 3 / Rung 5: Contexto → Clarificação → Execução → Validação → Recuperação. Os humanos se concentram nas fronteiras (frente: especificação e clarificação; trás: validação e recuperação); o agente roda por dentro. A mesma forma se aplica a domínios de tarefas discretas independentemente do substrato. Veja Lab de IA § Os cinco estágios.
Trabalho nas duas fronteiras
O padrão estrutural do trabalho no Tier 3 / Rung 5: a atenção humana se concentra na fronteira da frente (preparação de Contexto + Clarificação) e na fronteira de trás (Validação + Recuperação). Dentro do loop, o agente roda sem supervisão. A mudança é da revisão por linha para a direção e o julgamento por loop.
Padrão de tarefas discretas
A categoria de trabalho em que a IA opera como camada de execução: uma unidade clara (story, ticket, transação, consulta, cláusula contratual), outputs verificáveis, risco classificável. Engenharia, atendimento ao cliente, operações financeiras, revisão jurídica e pesquisa de conhecimento se encaixam. Os padrões v3 do framework se aplicam a essa categoria. Trabalho contínuo / criativo / interpessoal (vendas, criativo de marketing, design, RH) requer uma forma diferente de framework – adiado para uma futura trilha de aumento v4+.
Diálogo de clarificação
Um estágio operacional discreto no Tier 3 / Rung 5 em que o agente revisa a spec, expõe suas premissas e faz perguntas calibradas antes de executar. O /speckit.clarify do spec-kit e o modo plan + a ferramenta AskUserQuestion da Anthropic colocam o padrão em produção. Regra de custo: o custo da clarificação é limitado a minutos; o custo da correção escala com a profundidade da execução. Veja Guia de Especificação § Diálogo de clarificação.
Process design para IA
A disciplina de projetar fluxos de trabalho restritos e faseados dentro dos quais a IA opera de forma consistente – distinta da engenharia de prompts e da escrita de spec em si. Camada 5 dos Padrões de Execução de IA. Distingue o trabalho de Tier 3 / Rung 5 do trabalho de Tier 2 / Rung 4. Veja Padrões de Execução de IA § Camada 5.
Topologias de processo (as seis)
Vocabulário da Anthropic para como o pipeline que executa uma spec é estruturado: prompt chaining (etapas sequenciais de prompt único com validação intermediária), routing (classificar e despachar para prompts especializados), parallelization (executar subtarefas independentes em paralelo), orchestrator-workers (agente líder decompõe e despacha workers), evaluator-optimizer (gerador emparelhado com avaliador separado) e autonomous agents (exploração aberta com uso de ferramentas e loops de feedback). Regra de decisão: comece com prompt único; adicione complexidade apenas quando o valor por tarefa justificar o prêmio de tokens.
Validação por nível de risco
Portões de validação graduados por risco
O princípio de que a validação no Rung 5 não é monolítica – diferentes classes de ação recebem diferentes portões dependendo do raio de impacto, reversibilidade e consequência. Três posturas operacionais (HITL / HOTL / HOOTL) descrevem o gradiente. Uma equipe madura no Rung 5 opera as três simultaneamente, escolhendo o portão por classe de ação. Veja Lab de IA § Portões de validação graduados por risco.
HITL — Human-in-the-Loop
Uma postura de validação em que a aprovação humana é requerida antes que uma ação de IA seja executada. Padrão para ações irreversíveis de alto impacto: transações financeiras, deploys de produção, comunicações voltadas ao cliente, qualquer coisa que crie obrigação legal ou financeira. Limitada em throughput pela capacidade humana de revisão. Veja Lab de IA § Portões de validação graduados por risco.
HOTL — Human-on-the-Loop
Uma postura de validação em que a IA age de forma autônoma, mas o humano monitora com autoridade de intervenção (kill switch, rollback, override). Padrão para trabalho de produção reversível com forte cobertura de avaliações. Operacionalmente frágil quando tratada como monitoramento passivo – a fadiga de vigilância transforma um HOTL nominal em teatro de conformidade. Veja Lab de IA § Portões de validação graduados por risco.
HOOTL — Human-out-of-the-Loop
Uma postura de validação em que a IA age dentro de fronteiras pré-definidas, sem envolvimento humano em tempo real. Reservada para trabalho reversível em sandbox com testes fortes e um agente revisor em cada artefato. Merges de código em um repositório bem testado com um agente revisor tipicamente operam em HOOTL. Veja Lab de IA § Portões de validação graduados por risco.
Operational Design Domain (ODD)
As condições sob as quais um agente de IA é projetado para funcionar. Adaptado de SAE J3016 (direção) como o análogo mais limpo. Fora do ODD, o agente não faz alegações; o portão recua para o humano. Definir o ODD é parte do process design – quais ferramentas o agente tem, quais dados pode acessar, quais ações pode tomar. Veja Lab de IA § Portões de validação graduados por risco.
Agente revisor
O padrão de emparelhar um agente gerador com um agente avaliador separado (contexto diferente, às vezes um modelo diferente) que revisa o output antes de merge ou commit. Hoje o padrão de produção para revisão de código (CodeRabbit, Graphite Diamond, Greptile, GitHub Copilot review) e sendo adotado em atendimento ao cliente, processamento de documentos e outros domínios de tarefas discretas. Substitui a revisão humana síncrona em escala porque a matemática de custo por unidade entregue funciona de forma que a revisão humana em escala não funciona. Veja Engenharia para Confiabilidade § Agente revisor.
Responsável por permissões (Permissions Owner)
Um papel organizacional nomeado em sistemas de IA de produção. Responsável pelo que cada agente pode e não pode fazer, e pelo nível de portão de validação (HITL / HOTL / HOOTL) por classe de ação. Torna-se essencial assim que os agentes tocam sistemas de produção com efeitos colaterais irreversíveis. Veja Padrões de Execução de IA § Funções organizacionais.
Modos de falha e recuperação
Protocolo de estado bloqueado
O procedimento de Rung 5 / Tier 3 para lidar com um entregável em que o agente atingiu um limite estrutural. Detecte o estado bloqueado (limite de iteração atingido, mesmo padrão de falha recorrente ou problema subjetivo levantado por um usuário); pare de iterar; convoque uma sessão de recalibração; refaça a spec ou o contexto; reinicie o loop a partir de Contexto, não da Execução. A regra do Lab é explícita: não retome o trabalho manualmente. Veja Lab de IA § Protocolo de estado bloqueado.
Gargalo de IA
O modo de falha em Tier 2.5+ em que um entregável perde seu prazo porque o agente atingiu um limite estrutural (direção errada, spec ambígua, caso de borda subjetivo que ele não consegue resolver sozinho), não porque a capacidade humana é insuficiente. Cemri et al. (Why Do Multi-Agent LLM Systems Fail?, 2025) constataram que 41,8% das falhas em sistemas multi-agente se encaixam neste padrão. A resposta da liderança é tempo de recalibração, não redistribuição de trabalho ou aumento de pessoal. Veja Liderar a transformação § Gargalo de IA.
Sycophancy (bajulação)
LLMs defendendo posições erradas com confiança, de forma consistente. Medido em Sharma et al. (2023), Wen et al. (2024) e no trabalho da OpenAI sobre alucinação (2025). A literatura genuinamente discorda sobre se é uma correção de treinamento tratável ou um artefato estrutural do RLHF; a postura do framework é tratar a sycophancy como uma preocupação estrutural para fins de engenharia, independentemente da trajetória de treinamento. Construa salvaguardas de processo (sinal externo, agente revisor, recuperação de verdade-base, testes executáveis) em cada loop. Veja Engenharia para Confiabilidade § Sycophancy.
Caso de borda subjetivo
Uma falha trazida à tona por um usuário, não pelos testes ou pelo monitoramento: a IA acertou tecnicamente, mas errou em algo qualitativo (tom, intenção, voz da marca, alinhamento com o cliente) – embora o output técnico tenha passado em todas as verificações. O modo de falha dominante em maturidade alta. A recuperação é conversa, não correção – converse com o usuário, entenda o que ele estava tentando alcançar, atualize a spec ou o contexto. Veja Engenharia para Confiabilidade § Casos de borda subjetivos.
Recalibração vs depuração
Duas respostas operacionalmente distintas quando a IA está errada. Recalibração reconstrói o entendimento do agente via contexto novo, spec rearticulada ou brainstorm multi-perspectiva. Depuração corrige o artefato que o agente produziu. A literatura sobre autocorreção intrínseca é unânime de que um modelo que se comprometeu com uma direção errada não a perceberá com confiabilidade sozinho – o que significa que a maioria das falhas não triviais em T3 / R5 são problemas de recalibração disfarçados de problemas de depuração. Veja Engenharia para Confiabilidade § Recalibração vs depuração.
Economia da IA em maturidade
Custo por saída
A métrica de medição do Level 3 que substitui "tempo economizado pela IA" – custo por PR entregue, custo por ticket resolvido, custo por transação processada, custo por cliente atendido. A unidade varia por domínio; o princípio é consistente: o gasto total com IA sem denominador é sem sentido em maturidade. Veja Caso de negócio § Economia da IA em maturidade.
Margem bruta da IA
A razão entre o valor produzido e o gasto com inferência no nível da equipe ou do negócio. Negócios de IA na camada de aplicação operam com margem bruta de 40 a 55% contra 70 a 90% do SaaS tradicional – uma lacuna estrutural porque a inferência é um custo variável que escala com o uso. Se a lacuna se fecha ao longo do tempo é contestado; o piso é real e os negócios IA-nativos precisam planejar em torno dele. Veja Caso de negócio § Economia da IA em maturidade.
Economia de tokens
A disciplina de medir IA como infraestrutura de produção: custo por tarefa, custo por unidade entregue, throughput de agente por dólar, margem bruta da IA. Substitui "tempo economizado" como métrica vinculante no Level 3. Os custos por token estão caindo de 10 a 40× por ano, mas os custos por tarefa estão frequentemente subindo porque modelos de raciocínio, loops de agente e contextos mais longos consomem 10 a 100× os tokens de completions one-shot (paradoxo de Jevons aplicado à inferência). Veja Caso de negócio § Economia da IA em maturidade e Lab de IA § Economia de tokens.
← Voltar para o início · O framework de referência · Padrões de Execução de IA