Case visual: copiloto interno e agents de engenharia
- ⬜📄 Case visual: documentos em setor regulado (IDP)(AWS Bedrock — GenAI em Produção)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
O terceiro arquétipo é o que gera mais retorno por real investido e menos aparece em apresentação — porque não tem cliente para impressionar. É a IA voltada para dentro: o copiloto que responde sobre a política interna, o agent que consulta o sistema legado que ninguém quer tocar, o assistente que faz o engenheiro entender um código de 2011. Ninguém tira print disso. Mas é aqui que a empresa descobre se sabe operar IA — e é aqui que aparece o problema mais difícil dos três arquétipos: permissão.
Os cases públicos
| Empresa | Desenho | Número divulgado |
|---|---|---|
| Novo Nordisk (Dinamarca) | Milhares de assistentes internos, criados pelas próprias áreas | Tarefa que levava cerca de um dia caindo para a ordem de meia hora |
| United Airlines (EUA) | Tradução e entendimento de código e registros legados | Ganho relevante de produtividade dos times de desenvolvimento |
| Thomson Reuters (Canadá/EUA) | Platform engineering com agents | Ciclo de deploy saindo da ordem de dias para a ordem de horas |
| Adobe (EUA) | Knowledge Bases para suporte a desenvolvedores | Ganho de precisão na busca interna |
Repare no padrão do case de Novo Nordisk
O número que impressiona não é o tempo da tarefa — é a quantidade de assistentes. Milhares de assistentes internos não saem de um time central construindo um por um: saem de uma plataforma em que as áreas montam o próprio assistente sobre trilhos prontos. Esse é o desenho-alvo deste arquétipo, e é o que a onda 3 da arquitetura de referência chamou de self-service.
Três formas de IA voltada para dentro
"Copiloto interno" costuma virar um balaio de coisas diferentes na mesma iniciativa — e é por isso que muitos morrem sem escopo. São três desenhos distintos, com riscos e métricas diferentes. Escolha um por vez.
🧠 IA voltada para dentro
Copiloto de conhecimento
- →Responde sobre política, processo e produto interno
- →Só leitura — nunca altera estado
- →Risco principal: vazamento lateral entre áreas
- →Métrica: adoção semanal e taxa de resposta útil
Agents sobre sistemas internos
- →Consulta e (às vezes) executa em ERP, CRM, legado
- →Cada ação é uma tool com permissão explícita
- →Risco principal: ação irreversível sem confirmação
- →Métrica: tarefas concluídas sem intervenção
Produtividade de engenharia
- →Entender legado, escrever teste, revisar, documentar
- →Ferramenta na mão do dev, não serviço central
- →Risco principal: métrica de vaidade (linhas geradas)
- →Métrica: tempo de ciclo e retrabalho, não volume de código
A arquitetura do copiloto de conhecimento
A diferença estrutural para o copiloto de atendimento do módulo de front-office está na coluna de identidade. Ali, o cliente só podia ver os dados dele. Aqui, cada funcionário tem um recorte diferente do mesmo acervo — e o acervo inclui salário, avaliação de desempenho, processo jurídico e roadmap não anunciado. É o requisito mais difícil dos três arquétipos, e o que mais derruba projeto.
- → identidade e grupos do funcionário
- → filtro de metadados derivado da identidade
- → só se o grupo permitir: o restrito não entra no contexto
- → ação reversível, com confirmação e trilha
- Fora da AWS
- Segurança e identidade
- Rede e entrega
- Compute
- IA e machine learning
- Gestão e governança
A diferença estrutural para o copiloto de atendimento está na identidade: aqui cada funcionário tem um recorte diferente do mesmo acervo — e o filtro precisa ser de metadados, nunca de prompt.
- A pergunta chega autenticada. Slack, Teams ou portal — sempre com a identidade do SSO corporativo, nunca anônima.
- A identidade é propagada. Os grupos do funcionário viajam até a camada de retrieval. Sem isso, permissão vira instrução no prompt — e instrução não é controle.
- O filtro decide o que existe. O que a pessoa não pode ler simplesmente não é recuperado. O documento restrito nunca entra no contexto.
- Responder com citação. Fonte sempre visível — é o que permite ao funcionário conferir e ao time descobrir conteúdo desatualizado.
- Agir, com a autoridade certa. A ação executa com a permissão de quem pediu, nunca com credencial de serviço ampla — senão o assistente vira caminho de escalonamento de privilégio.
- Medir adoção, não habilitados. Ativos semanais, perguntas por usuário, taxa de resposta útil e custo por funcionário ativo.
O problema que mata copiloto interno: permissão
O incidente típico não é alucinação — é vazamento lateral: alguém pergunta algo inocente e a resposta cita um documento que aquela pessoa não deveria poder ler. Como a citação é honesta e a resposta é correta, o problema só aparece quando alguém percebe. E aí o projeto inteiro é suspenso.
Prompt não é controle de acesso
Se o documento restrito entrou no contexto, o vazamento já aconteceu — o resto é sorte. Permissão precisa ser filtro de metadados aplicado na busca, derivado da identidade real do usuário. Consequência prática de projeto: se a sua base de conhecimento não tem metadado de confidencialidade confiável, o caminho crítico do copiloto interno não é o modelo, é a curadoria. Planeje isso no cronograma.
Comece por um domínio de baixa sensibilidade
TI e suporte interno (como usar a VPN, como pedir acesso, como configurar a máquina) são o melhor primeiro domínio: volume alto de perguntas repetidas, conteúdo já escrito, quase nada confidencial e um time dono que sente o alívio na primeira semana. Deixe RH e jurídico para depois de a máquina de permissão estar provada.
Agents que tocam sistemas internos
Quando o assistente deixa de responder e passa a fazer, a conversa muda de natureza. A regra é subir a escada de autonomia um degrau por vez, e nunca pular direto para o topo porque a demo foi bem.
A permissão é do usuário, não do agent
O erro perigoso aqui é dar ao agent uma credencial de serviço poderosa e deixá-lo agir em nome de qualquer um. A ação precisa acontecer com a autoridade da pessoa que pediu — é o que impede que "pergunte ao assistente" vire um caminho de escalonamento de privilégio. Se a pessoa não podia abrir aquele chamado sozinha, o agent também não pode abrir por ela.
Produtividade de engenharia
É a frente com o retorno mais rápido e a medição mais traiçoeira. O ganho real raramente está em "escrever código novo mais rápido" — está em entender código que ninguém entende, escrever o teste que ninguém escreveu e documentar o que está só na cabeça de uma pessoa. É exatamente o que o case de tradução de sistemas legados descreve.
| Métrica | Por que atrai | Por que engana |
|---|---|---|
| Linhas de código geradas | Fácil de coletar e cresce sempre | Mede volume, não valor — mais código pode ser exatamente o problema |
| Sugestões aceitas | Vem pronta da ferramenta | Aceitar não é entregar; parte é revertida no mesmo dia |
| % de devs usando | Vira slide bonito rápido | Uso não é ganho; mede curiosidade nas primeiras semanas |
| Tempo de ciclo de PR | Difícil de falsear | Sinal real — do commit ao merge é o que o time sente |
| Retrabalho e taxa de reversão | Ninguém gosta de olhar | O contrapeso obrigatório: velocidade que gera reversão não é velocidade |
| Tempo até o primeiro PR de um novato | Exige acompanhar pessoas | A melhor prova de que o copiloto de código funciona em base legada |
Meça em par, sempre
Velocidade sem qualidade é dívida acelerada. Acompanhe sempre um par: tempo de ciclo com taxa de reversão, cobertura de teste com bugs em produção, volume de PR com tempo de revisão. Um número sozinho nessa frente sempre conta uma história melhor do que a realidade.
Um funcionário pergunta ao copiloto interno sobre a política de promoção e a resposta cita, corretamente, um documento de RH com faixas salariais que ele não deveria acessar. Onde está a falha?
A métrica que não mente: adoção
Todo projeto de IA interna tem um pico de uso na semana do lançamento. O que decide se ele é produto ou piloto é o que acontece na semana seis. Estas são as métricas que contam a verdade — e o custo por funcionário ativo é o número que a diretoria vai pedir.
| Métrica | O que revela | Sinal de alerta |
|---|---|---|
| Ativos semanais ÷ habilitados | Se o assistente entrou na rotina | Queda contínua depois da semana 3 — a novidade passou e o valor não sustentou |
| Perguntas por usuário ativo | Profundidade do uso | Uma pergunta por pessoa por semana costuma ser curiosidade, não hábito |
| Taxa de resposta marcada como útil | Qualidade percebida | Abaixo de ~60% investigue conteúdo antes de trocar de modelo |
| Perguntas sem fonte na base | Lacuna de conteúdo | É a melhor fila de trabalho que o projeto produz — priorize por frequência |
| Custo por funcionário ativo | Sustentabilidade | Sobe enquanto a adoção cai: o pior cenário, e o mais comum em piloto que não vira produto |
A lista de perguntas sem resposta vale mais que o assistente
Toda pergunta que o retrieval não conseguiu ancorar em nenhuma fonte é um pedaço de conhecimento que a empresa não documentou. Agrupadas por frequência, essas perguntas são a melhor lista de prioridades de documentação que uma organização pode ter — e várias empresas relatam que esse subproduto rendeu mais que o assistente em si.
O que costuma dar errado
- Assistente genérico da empresa inteira: tenta responder sobre RH, TI, jurídico e produto ao mesmo tempo, responde tudo com mediocridade e ninguém volta na segunda semana.
- Permissão resolvida no prompt: o vazamento lateral acontece, alguém percebe, e o projeto inteiro é suspenso — inclusive as partes que funcionavam.
- Base de conhecimento que é o Confluence inteiro: indexar tudo inclui a página de 2019 que contradiz o processo atual. O modelo cita as duas, e a confiança do usuário morre na terceira resposta contraditória.
- Sem dono de conteúdo: quando a resposta está errada porque o documento está errado, não existe ninguém responsável por corrigir. A fila de correção vira backlog eterno.
- Sucesso medido por habilitados: "5.000 funcionários com acesso" no slide, 180 usando de verdade.
- Agent com credencial de serviço poderosa: ele age em nome de todo mundo com a mesma autoridade, e "pergunte ao assistente" vira caminho de escalonamento de privilégio.
- Pular para nível 4 de autonomia porque a demo foi bem: a primeira ação irreversível errada em sistema interno queima o projeto por dois anos.
- Sem canal de feedback: o 👍/👎 é a fonte de dado mais barata do projeto e frequentemente é a última coisa que alguém implementa.
Linha do tempo
Checklist para replicar
- Escolha UM domínio de baixa sensibilidade e alto volume de perguntas repetidas.
- Encontre o dono do conteúdo antes de começar — sem dono, a correção nunca acontece.
- Cure o acervo: arquive o que está obsoleto antes de indexar, porque documento contraditório indexado vira resposta contraditória com citação.
- Torne o metadado de confidencialidade obrigatório na ingestão, mesmo no domínio aberto.
- Propague a identidade do SSO até a camada de retrieval e aplique filtro de metadados na consulta.
- Teste o vazamento lateral de propósito: um usuário sem acesso, várias formulações, antes de abrir para a empresa.
- Ligue feedback 👍/👎 e a coleta de perguntas sem fonte no primeiro dia.
- Meça ativos semanais, não habilitados — e acompanhe a curva até a semana seis.
- Comece no nível 1 de autonomia; suba um degrau por vez, com dado.
- Toda ação executa com a autoridade de quem pediu, nunca com credencial de serviço genérica.
- Crie um inference profile por assistente para ter custo por funcionário ativo desde o começo.
- Trate a fila de perguntas sem resposta como backlog de documentação, priorizado por frequência.
- Só abra o self-service depois que os trilhos (KB por domínio, tiers, permissão, observabilidade) estiverem provados em dois domínios.
Depois de três meses, o relatório mostra 5.000 funcionários com acesso ao copiloto, 4.100 sugestões aceitas e 62 mil perguntas no acumulado. O que falta para saber se o projeto está funcionando?
Um agent interno vai passar a abrir chamados de acesso a ambientes. Qual desenho de permissão é o correto?
Você concluiu a trilha AWS Bedrock
Você começou sem saber o que era o Bedrock e termina com o conjunto completo: a API e as modalidades, tool use, RAG gerenciado, agents, guardrails, preço e FinOps, a arquitetura de referência de sete camadas, os quatro caminhos do Claude na AWS e os três arquétipos que cobrem quase toda IA corporativa — front-office, back-office e uso interno. O próximo passo não é outro módulo: é pegar um processo real da sua empresa, medir o baseline desta semana e desenhar as sete camadas em cima dele.
Perguntas frequentes
❓ Por que copiloto interno dá mais retorno que produto voltado ao cliente?
❓ Por onde começar um copiloto de engenharia?
❓ Como medir se o copiloto interno está funcionando?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…