A Smarsh Roda a AWS Agentic AI Lens como Código. Sem Evidência, o Item Fica 'Not Reviewed'.

A AWS Agentic AI Lens reúne 150 boas práticas, organizadas em 41 perguntas e seis pilares. A Smarsh transformou essa lente em uma skill do Claude que revisa um repositório contra cada uma delas, segundo um post de outubro de 2026 no AWS Architecture Blog. Cada status precisa citar evidência encontrada no repositório. Um item sem sinal recebe Not Reviewed em vez de um palpite.

Essa última regra é a parte interessante. Nas organizações com que trabalhamos, frameworks de governança vivem em PDF, página de wiki ou planilha, que alguém lê e depois interpreta. A versão da Smarsh roda. Ela produz um status para cada item, recusa inventar um status que não consegue sustentar, e o build que monta o relatório para quando a saída não bate com o framework.

Um framework que roda, falha fechado e é testado pelo próprio conjunto de eval se comporta como controle. Um framework que só é lido se comporta como referência.

Uma ressalva antes dos detalhes. O post é co-marketing de fornecedor, publicado pela AWS, e a página não traz autor. Segundo o post, a lente ainda não pode ser selecionada como lente no AWS Well-Architected Framework. Os números, nas palavras do texto, “refletem os primeiros usos internos da Smarsh e os resultados que o time busca alcançar”. Leia o que segue como um padrão de desenho que vale copiar, com evidência ainda fina.

A lente vira dado

O primeiro movimento é tratar o framework como conjunto de dados. Cada uma das 150 boas práticas tem um ID, e a skill reporta contra esses IDs. A escala de status tem exatamente cinco valores: Compliant, Partially Compliant, Non-Compliant, Not Applicable e Not Reviewed.

Um vocabulário fechado assim faz dois trabalhos. Torna os resultados comparáveis entre repositórios e ao longo do tempo, porque “quase tudo certo” fica fora das respostas permitidas. E dá à engrenagem em volta do modelo algo para conferir. Uma revisão em texto livre pode dizer qualquer coisa. Uma revisão presa a IDs conhecidos e cinco status pode ser validada antes que alguém a leia.

Compare com a linha de base. Nos fixtures de teste do post, o modelo sem a skill produziu “checklists ad hoc de 18 a 39 itens, sem rastreabilidade para a lente”. Esses checklists podiam ter boas observações. Só que ninguém conseguia mapeá-los de volta ao framework, então ninguém sabia quais das 150 práticas tinham sido examinadas e quais tinham ficado de fora.

A regra de honestidade

“Todo status precisa citar evidência encontrada no repositório; itens sem sinal são marcados Not Reviewed em vez de adivinhados.”

Essa frase concentra quase todo o valor de governança. Um modelo de linguagem a quem se pede para preencher 150 linhas vai preencher 150 linhas. Sem uma regra que separe “verifiquei e passa” de “não encontrei nada”, o relatório parece completo e superestima a cobertura em silêncio. Um Compliant confiante sem citação é pior que um campo vazio, porque o campo vazio ao menos manda você olhar.

Not Reviewed transforma ausência de evidência em saída visível. Quem lê o relatório vê exatamente onde o revisor não tinha base. Na nossa leitura, essa lista é uma fila de trabalho: alguns itens vão pedir que uma pessoa confira algo fora do repositório, outros vão apontar controles que ainda não existem.

A exigência de citar evidência faz uma segunda coisa. Torna cada status auditável depois. Quem discorda de um Compliant abre o arquivo citado e discute com a evidência, sem precisar discutir com o modelo.

O builder falha fechado

O post diz com todas as letras: “IDs de boas práticas desconhecidos ou status inválidos abortam o build, e itens alucinados não conseguem passar em silêncio.”

O modelo ainda pode errar, mas a esteira em volta dele barra resultados com IDs desconhecidos ou status inválidos. Se o modelo inventar uma boa prática ausente da lente, ou devolver um status fora dos cinco valores, o relatório deixa de ser montado.

É o mesmo princípio que aplicamos a qualquer gate entre um agente e a produção. A validação mora em código determinístico, e o padrão diante de falha é parar. Um revisor que se degrada em saída plausível vira passivo, porque a saída degradada tem a mesma cara da boa.

A skill tem seu próprio eval

A Smarsh testou a skill contra dois repositórios sintéticos de fixture. Com a skill, o modelo cumpriu 16 de 16 expectativas. Sem ela, a linha de base cumpriu 8 de 16.

Trate esse número com cuidado. Dois fixtures sintéticos formam uma amostra pequena e artificial, e ambos substituem repositórios de produção. O eval mede se a skill faz o que os autores esperam em entradas conhecidas. A precisão da revisão em código real fica fora dessa medida, e o post omite quantas horas uma revisão leva.

A existência do eval pesa mais que a nota. Um revisor com expectativas escritas pode ser alterado e rodado de novo. Quando a lente ganhar versão nova, ou o prompt mudar, ou o modelo mudar, o time tem um teste de regressão. Um processo de governança feito só por pessoas lendo um checklist fica sem essa verificação quando o checklist muda.

O que apareceu

Entre as lacunas que o post relata no uso da própria Smarsh estavam um authorizer de gateway “rodando com autenticação desligada sob uma aceitação de risco documentada” e rate limiting “registrado como TODO”.

Nenhum dos dois é exótico. Ambos são o tipo de coisa que uma revisão manual pode deixar passar: quem lê vê a aceitação de risco e segue, ou vê o TODO e supõe que alguém é dono dele. Um revisor obrigado a citar evidência traria os dois de volta a cada execução, apontando o arquivo. Decidir se a aceitação de risco ainda vale continua sendo trabalho humano. A diferença é que a pergunta volta à mesa a cada revisão.

Do relatório ao gate

O próximo passo declarado pela Smarsh é “impor governança tornando o workbook da revisão evidência obrigatória no processo de marcos e gates de projeto da Smarsh antes que workloads agênticos cheguem à produção”.

É esse passo que converte uma ferramenta útil em controle. Um relatório que alguém talvez leia é consultivo. Um relatório que o marco exige para avançar é imposição. Repare no tempo verbal: o post descreve isso como plano, sem afirmar que o gate já está ativo.

O padrão conversa com o que mostramos em auditar a revisão antes do merge: o gate confere que existe uma revisão com o formato certo e com evidência, e as decisões de julgamento ficam com pessoas. A mesma lógica liga este texto a fazer o agente manter um diário e a dar um fiscal ao sistema de IA. Uma regra que ninguém executa se desgasta. Uma regra que roda a cada mudança mantém a forma.

Onde as pessoas continuam

A máquina produz um status por item, com evidência. Na nossa leitura, três responsabilidades devem ficar com pessoas em qualquer versão desse desenho: triar a lista de Not Reviewed, decidir se uma aceitação de risco documentada ainda se sustenta e ser dono da correção de cada item Non-Compliant.

Essa divisão mantém o revisor honesto na prática. Se os itens Not Reviewed se acumulam sem dono, o relatório vira teatro. Se alguém cuida dessa lista, ela encolhe.

Faça isto agora

Escolha um framework de governança que sua organização já diz seguir. Um padrão interno de segurança, a lente well-architected de um provedor de nuvem, o checklist de um regulador. Depois siga quatro passos.

Converta o framework em dado. Dê a cada item um ID estável e defina um conjunto fechado de status, incluindo um que signifique “nenhuma evidência encontrada”.
Escreva a regra de honestidade nas instruções do revisor: todo status cita um arquivo ou artefato, e ausência de evidência é reportada, nunca adivinhada.
Coloque um validador determinístico entre o revisor e o relatório. IDs desconhecidos e status inválidos param o build.
Monte alguns repositórios de fixture com respostas conhecidas e mantenha-os como conjunto de regressão. Rode sempre que o framework, o prompt ou o modelo mudar.

Só depois que esses quatro estiverem de pé o relatório deve virar evidência obrigatória em um gate de release. Tornar obrigatório um relatório sem validação produz um documento confiante em que ninguém pode confiar.

Fontes

AWS. “Automating agentic AI Well-Architected reviews with the AWS Agentic AI Lens.” Outubro de 2026.

A Victorino ajuda organizações de engenharia a transformar frameworks de governança em revisões executáveis que citam evidência e falham fechado: contato@victorino.com.br | www.victorino.com.br