A Governança Desce para a Camada de Especificação

Já argumentamos que, quando um agente faz o trabalho, a interface que ele produz se torna descartável. A apresentação, o dashboard, o relatório formatado: são renderizações que um humano pediu, não a coisa sobre a qual o agente raciocinou. Aquele ensaio deixou uma pergunta deliberadamente em aberto. Se a tela não é mais onde o trabalho acontece, para onde vai a governança?

Esta é a resposta. A governança desce para a camada de especificação estruturada. A apresentação vira saída. A especificação vira o contrato.

A Interface Sempre Foi um Acidente

O argumento de Alejandro Gonzalez na Mozilla.ai é direto: a interface não é mais o produto. Durante trinta anos entregamos software em que a tela era o artefato. Uma planilha era as células que você via. Uma apresentação eram os slides que você clicava. Um documento era a página que você rolava. A estrutura por baixo existia apenas para produzir a vista.

Esse arranjo era um acidente de quem era o consumidor. Humanos não conseguem ler uma representação binária de um modelo financeiro, então embrulhamos tudo numa grade. Humanos não raciocinam sobre um argumento narrativo como estrutura de dados, então embrulhamos em slides. As categorias que tratamos como naturais (slides, planilhas, documentos) não são leis do software. São o resíduo de uma única restrição: o leitor tinha olhos e um cursor, e nada além disso.

Remova essa restrição e as categorias se dissolvem. Um agente não precisa da grade. Não clica por slides. Quando um agente consome um modelo financeiro, a grade é sobrecarga que ele precisa parsear para depois conseguir raciocinar. A representação legível por humanos, aquilo que passamos trinta anos otimizando, agora é a pior entrada possível.

Então a estrutura se inverte. A representação legível por máquina deixa de ser subproduto da vista. Passa a ser a coisa em si. A vista passa a ser uma entre várias renderizações possíveis dela.

As Cinco Partes de um Sistema Nativo de Agentes

Gonzalez não para no slogan. Ele decompõe um sistema nativo de agentes em cinco partes, e é nessa decomposição que a governança encontra sua nova casa.

Primeiro, uma representação interna estruturada. A fonte única da verdade, legível por máquina, sem amarra a nenhum formato de exibição. Esta é a especificação.

Segundo, renderizadores. Eles transformam a especificação em vistas humanas: uma apresentação, um dashboard, um PDF. Plurais e descartáveis. Você os gera sob demanda e os joga fora. A vista deixou de ser preciosa porque deixou de ser a fonte.

Terceiro, validadores. Eles checam a especificação quanto a coerência e segurança antes de qualquer coisa renderizar ou executar. O modelo é internamente consistente? O plano viola uma política? Validadores não são cosméticos; são o portão.

Quarto, sistemas de diff e aprovação. Eles tornam toda mudança na especificação visível e revisável. Um humano aprova uma mudança estruturada, não uma captura de tela de um slide.

Quinto, compatibilidade com formatos legados. O sistema ainda consegue emitir um PowerPoint ou um Excel quando um humano ou outra ferramenta exige. Compatibilidade, não dependência.

Repare onde o humano se senta nessa lista. Não no renderizador. O renderizador é descartável. O humano se senta no validador e no portão de aprovação, revisando a especificação. A governança não desapareceu quando a interface se tornou descartável. Ela desceu um andar.

O Contrato Precisa Ser Executável por Máquina

O texto da Mozilla.ai dá o enquadramento de sistema. O trabalho de Allie Paschal, perguntando se desenhamos para humanos ou para máquinas, fornece a prova de que isso é construível, não teórico.

O exemplo dela é um componente de Banner. No mundo antigo, um designer escreve prosa para o design system: “Use a variante de erro para mensagens críticas e bloqueantes. Use a variante de aviso para problemas não bloqueantes que o usuário deveria conhecer.” Um humano lê isso, interpreta e escolhe uma variante. A prosa é a especificação, e ela não é aplicável. Dois designers leem de duas formas. Um agente lê e adivinha.

A jogada de Paschal é transformar a resolução da variante numa tabela lógica. A variante do banner é função de duas entradas: message_type e user_impact. Uma mensagem bloqueante de alto impacto resolve para error. Uma mensagem informativa não bloqueante resolve para info. A tabela é executável por máquina. Não sobra interpretação. Alimente as duas entradas e a variante está determinada.

É assim que a camada de especificação se parece quando você a leva a sério. O design system deixa de ser prosa que se confia que um humano honre. Vira uma estrutura que um agente executa e que um validador consegue checar. A pergunta “este banner escolheu a variante certa?” deixa de ser opinião de code review e vira um teste determinístico contra a tabela.

Esta é a mesma descida que traçamos em outros lugares. Argumentamos que o design system se torna a camada de aplicação da governança de IA. Paschal mostra o mecanismo. Restrições em prosa falham como entrada de agente porque agentes não honram intenção; eles executam estrutura. Então a restrição precisa virar estrutura. A regra precisa ser codificável, ou não é regra.

Onde Coerência, Segurança e Aprovação Agora Moram

Junte os dois textos e o novo mapa fica claro.

A coerência morava na tela. Um revisor olhava a apresentação e sentia se a história se sustentava. Agora a coerência mora no validador. A especificação ou passa na checagem de consistência ou não passa, e a checagem roda antes de qualquer apresentação existir.

A segurança morava no julgamento de um humano no momento da apresentação. Alguém pegava o slide que vazava o nome de um cliente ou o dashboard que expunha um número que não deveria. Agora a segurança mora no validador e no portão de política. A checagem dispara contra a especificação, não contra a renderização, o que significa que dispara uma vez, de forma determinística, em vez de ser relitigada toda vez que alguém regenera a vista.

A aprovação humana era aprovação de um artefato: você aprovava esta versão da apresentação. Agora a aprovação é de um diff contra a especificação. Você não está aprovando pixels. Está aprovando uma mudança estruturada, com sua proveniência e seu antes e depois visíveis. Este é o mesmo princípio que descrevemos ao argumentar que a própria empresa vira uma camada de governança expressa como código. O que você governa é a estrutura, não a aparência.

A tela não some. As pessoas ainda precisam olhar as coisas. Mas a tela deixa de ser o ponto de controle. Você não consegue governar no renderizador porque o renderizador é descartável e plural. Você governa no único lugar que é singular e autoritativo: a especificação.

O Que Isso Custa e o Que Compra

Há um custo real. Escrever um validador é mais difícil do que dar uma olhada num slide. Codificar uma regra de design como tabela lógica dá mais trabalho do que escrever uma frase sobre ela. Muitos times vão resistir porque a versão em prosa parece pronta e a versão estruturada parece engenharia a mais.

Mas a versão em prosa nunca esteve pronta. Era inaplicável, e toleramos isso porque havia sempre um humano no circuito para interpretá-la. Tire o humano do circuito, entregue a prosa a um agente, e a ausência de estrutura vira um modo de falha ativo. O agente não interpreta sua intenção. Ele age sobre o que está de fato escrito. Se o que está escrito é “use bom senso”, o agente não tem senso algum para usar.

O que você compra é governança que escala sem um humano a cada renderização. O validador roda mil vezes de graça. A tabela lógica resolve um milhão de banners de forma idêntica. O diff torna toda mudança auditável, seja um humano ou um agente que a fez. Essa é a troca: mais trabalho na frente, na especificação, muito menos trabalho por artefato, e um ponto de controle que não depende de alguém estar acordado para pegar o slide ruim.

Faça Isto Agora

Escolha um artefato que seu time produz e que um agente agora toca. Uma apresentação, um relatório, um componente configurado, qualquer coisa que um agente gera ou modifica.

Faça três perguntas. Qual é a representação estruturada por baixo dele, e essa representação é a fonte da verdade ou só um subproduto da vista? Onde está a regra que diz o que torna este artefato correto, e essa regra é prosa que um humano interpreta ou uma estrutura que uma máquina checa? Quando uma mudança acontece, você revisa a saída renderizada ou o diff estruturado?

Se a regra mora na prosa e a revisão acontece na tela, sua governança está sentada no andar descartável. Desça-a. Escreva um validador. Transforme uma restrição em prosa numa tabela lógica. Revise um diff em vez de uma renderização. Você não está adicionando burocracia. Está realocando o ponto de controle para o único andar que continua sustentando carga depois que o agente ignora a interface.

---

Fontes

• Mozilla.ai. “The Interface Is No Longer the Product.” Maio de 2026.
• UX Collective. “Should I Design for Humans or Machines?.” Maio de 2026.

A Victorino ajuda equipes a mover a governança para a camada de especificação onde os agentes de fato operam: contato@victorino.com.br | www.victorino.com.br