A IA nunca publica sozinha; aprovação dupla; idempotência

Selo de estado: Preview (teto atual do produto) · Curso ACD-430 — Governança de IA: custo, egress, LGPD e aprovação humana · Aula 5 de 7 · Atualizado em 2026-10-04.

Objetivo#

Ao final desta aula você vai aprovar uma ação proposta — percorrer o fluxo pendente → aprovada → executada respeitando a segregação de funções, e explicar por que a mesma ação aprovada duas vezes não executa o efeito duas vezes.

Vídeo#

Identificador no manifesto: acd-430-05-aprovacao-humana-writeback · duração-alvo 7 min · tela do produto: /actions.

Roteiro (capítulos):

00:00–00:50 — O princípio que atravessa toda a IA do produto: a IA propõe, o humano confirma. Nada material acontece sem alguém apertar o botão.
00:50–02:10 — Geração assistida: o artefato vem com validacao determinística; a escrita só acontece na confirmação. E o text-to-SQL que só propõe SELECT.
02:10–03:50 — Ações materiais: segregação de funções (quem propõe não aprova), aprovação dupla para alto impacto, e a máquina de estados completa com os desvios.
03:50–05:10 — Idempotência: sha256(ação ‖ params canônicos), por que a ordem das chaves não muda a chave, e o preview que mostra o efeito antes de executar.
05:10–06:10 — O desligamento ACTIONS_DISABLE é opt-in (sem configuração, a execução está ligada) e a correção pública de um claim antigo.
06:10–07:00 — Exemplo Aurora, erros comuns, estado da capacidade e o "faça você mesmo".

Conteúdo#

A IA propõe; o humano confirma

Na geração assistida, a IA devolve um artefato estruturado (uma medida, um visual, um esqueleto de dashboard) acompanhado de um campo validacao preenchido por código determinístico — não pelo modelo. O preview é o próprio artefato, e a escrita só acontece quando você confirma, pelas mesmas ações do editor que você usaria à mão. Nenhuma escrita nasce da IA. Pedir algo impossível devolve rascunho: true com os erros listados, em vez de um artefato quebrado.

O mesmo princípio vale para o text-to-SQL: ele propõe apenas SELECT — nunca DML nem DDL —, e você revisa antes de rodar. Uma medida proposta usa a notação real do produto, por exemplo SOMA(valor) dentro de MEDIDA('Receita'); se a fórmula não compila, ela não vira medida.

Ações materiais: segregação de funções e aprovação dupla

Para efeitos materiais (escrever de volta num sistema, disparar uma ação no mundo), existe uma governança de aprovação:

Quem propõe não pode aprovar a própria ação. É a regra de ouro, e é checada na máquina de estados, não na interface.
Ações de alto impacto exigem dois aprovadores distintos — ambos diferentes de quem propôs. Um insider ou uma conta comprometida não causa dano material sozinho.
Cada ação do catálogo declara o seu raio de impacto (baixo · medio · alto); registrar "alto" sem aprovação dupla é impossível — o registro normaliza.
Cada ação usa uma credencial própria, nunca a credencial de leitura do datalake.
O preview mostra, antes de qualquer execução, o que vai acontecer item a item, se é reversível e como desfazer — para o aprovador decidir com informação.

Fluxo de estados:

Estado	Chega-se nele por
`pendente`	proposta criada (`action.propose`)
`aprovada`	aprovação de 1 ou 2 pessoas distintas (`action.approve`)
`executada`	execução bem-sucedida da ação aprovada
`rejeitada`	recusa explícita de um aprovador (`action.reject`)
`cancelada`	cancelamento (`action.cancel`), a partir de `pendente` ou `aprovada`
`falha`	a execução tentou e falhou

Idempotência: a mesma ação não acontece duas vezes

A chave de idempotência é sha256(ação ‖ parâmetros canônicos). "Canônicos" significa que as chaves do objeto de parâmetros são ordenadas recursivamente antes do hash: {a:1, b:2} e {b:2, a:1} produzem a mesma chave. Com isso, a mesma ação com os mesmos parâmetros tem sempre a mesma chave, e o executor nunca aplica o mesmo efeito duas vezes — nem no clique duplo, nem no retry depois de um timeout.

O desligamento é opt-in, não um padrão conservador

A documentação pública já afirmou que ações/writeback vinham com egress "desligado por padrão" e que a ativação dependia de liberação manual da nossa equipe. As duas coisas são falsas e foram corrigidas. Os interruptores (ACTIONS_DISABLE para ações, o de egress para IA) ficam desligados quando não configurados — ou seja, sem configuração explícita a execução está ligada. Quem quiser a postura conservadora precisa ligar o interruptor deliberadamente. E não existe, em lugar nenhum do produto, um gate de liberação caso a caso operado por nós.

Quando o desligamento global está ligado, nenhuma ação material roda e a tentativa é registrada como bloqueada — nada é executado pela metade.

Quem pode aprovar

Confirmar artefatos de geração e publicar depende de papel de edição/publicação. Aprovar ações materiais depende de papel aprovador (owner/admin); ação de alto impacto exige dois aprovadores distintos, ambos diferentes de quem propôs.

Exemplo: a Aurora Varejo devolvendo a meta ao ERP

O alerta determinístico da Aurora Varejo detecta que a filial de SP passou da meta e o time quer registrar isso de volta num sistema externo por webhook. Ana (member, com papel de proposição) propõe a ação: o preview mostra o destino, os campos, que a ação não é reversível e o raio de impacto alto. Por ser alto, o fluxo pede dois aprovadores distintos — Ana não pode ser nenhum deles. Maria (owner) aprova; João (admin) aprova; só então a ação sai de aprovada para executada.

No dia seguinte, Ana propõe exatamente a mesma ação com os mesmos parâmetros, achando que a primeira não tinha saído. A chave de idempotência é idêntica, e o executor não repete o efeito. Em /auditoria, o rastro conta a história inteira: action.propose (Ana), dois action.approve (Maria e João), a execução — e nenhuma segunda execução.

Erros comuns

Achar que a IA publicou sozinha. Se algo foi escrito, houve uma confirmação humana. Procure o action.approve ou a ação do editor na trilha.
Tentar aprovar a própria proposta. É negado por desenho, não por falta de permissão — e trocar o papel não resolve.
Supor que "não configurei nada" significa "está bloqueado". O interruptor é opt-in; sem ele, está ligado.
Clicar duas vezes e temer o efeito duplo. A idempotência cobre; o que você vai ver é a mesma chave, não dois efeitos.
Confundir validacao com opinião do modelo. Ela é preenchida por código determinístico sobre a saída do modelo.
Esperar que rejeitada e cancelada sejam a mesma coisa. Rejeição é decisão de aprovador; cancelamento é desistência do fluxo.

O que esta capacidade NÃO faz, e em que estado está

Hoje não existe um painel self-service de aprovações no console: o fluxo vive na superfície de ações (/actions), e o catálogo de ações executáveis tem um único tipo — webhook (Sheets, ERP e CRM entram depois, sem tocar o framework de aprovação/idempotência). A capacidade não executa nada sem aprovação, não usa a credencial de leitura do datalake e não reverte automaticamente o que for irreversível — ela avisa antes.

O selo de C13.5 é Preview: a máquina de estados de aprovação e a idempotência são cobertas por testes; o que não foi verificado é a execução de efeito material contra um destino externo real — a ativação real é um gate humano pendente. Nada aqui é GA.

Faça você mesmo#

No workspace de treino Aurora Varejo (abra /actions no console):

Peça à geração assistida uma medida simples (por exemplo MEDIDA('Receita') com SOMA(valor)) e não confirme — observe que nada foi escrito no modelo. ⚠️ Este passo consome orçamento de IA do workspace.
Peça algo impossível (uma medida sobre uma coluna que não existe) e confirme que a resposta vem como rascunho, com os erros listados pela validação determinística.
Proponha uma ação material de webhook para um destino *.example e leia o preview inteiro: efeitos item a item, reversibilidade, raio de impacto.
Tente aprovar a sua própria proposta e registre a recusa — anote qual regra foi violada.
Aprove com outra pessoa. Se o raio de impacto for alto, confirme que o fluxo exige dois aprovadores distintos antes de sair de pendente.
Proponha de novo a mesma ação com os mesmos parâmetros, mudando apenas a ordem das chaves — confirme que a chave de idempotência é a mesma e que o efeito não é repetido.
Em /auditoria, monte a sequência do ciclo: action.propose → action.approve (×1 ou ×2) → execução, com quem fez cada passo.
Escreva em duas linhas qual postura você adotaria na Aurora: deixar o interruptor de ações como está (ligado) ou ligá-lo deliberadamente — e por quê.

Você terminou quando tiver uma ação que saiu de pendente a executada com propositor ≠ aprovador registrado em /auditoria, a recusa da auto-aprovação anotada, e a prova de que a segunda proposta idêntica não repetiu o efeito.

Checagem rápida#

Três perguntas no final da aula, corrigidas no servidor. A aula só conta como concluída depois da checagem.

Documentação relacionada#

Capacidades ensinadas#

C13.5 — o selo exibido na aula é sempre o estado mais conservador entre as capacidades citadas; nada aqui é "GA".