Saltar al contenido
Docs

Esta página aún no está traducida — estás leyendo la versión en portugués. Ver en portugués

PreviewActualizado el 2026-09-08

Aprovação humana e auditoria

A IA propõe, o humano confirma — como funcionam a aprovação (inclusive dupla), a idempotência e a trilha de auditoria da IA.

En esta página (7)

Um princípio atravessa toda a IA do ingestia.io: a IA propõe; o humano confirma. Nada material acontece sem uma pessoa autorizada apertar o botão — e tudo que a IA faz deixa trilha de auditoria. Esta página reúne como isso funciona na geração assistida e nas ações/writeback, e o que fica registrado.

Maturidade

As capacidades com LLM são Preview. A máquina de estados de aprovação é coberta por testes; o que não foi verificado é a execução de efeito material contra um destino externo real.

Correção de uma afirmação anterior. Esta página dizia que ações/writeback vêm com o egress "desligado por padrão" e que a ativação dependia de "liberação manual da nossa equipe". As duas coisas são falsas. Os interruptores (ACTIONS_DISABLE para ações, AI_EGRESS_DISABLE para egress de IA) são opcionais e ficam DESLIGADOS quando não configurados — ou seja, sem configuração explícita a execução está ligada, não bloqueada. E não existe, em lugar nenhum do produto, um gate de liberação caso a caso operado por nós. Quem quiser a postura conservadora precisa ligar o interruptor deliberadamente.

1. A IA nunca publica sozinha#

Na geração assistida, a IA devolve um artefato estruturado (medida, visual, esqueleto de dashboard) acompanhado de um campo validacao preenchido por código determinístico. O preview é o próprio artefato; a escrita só acontece quando você confirma pelas ações existentes do editor (addMeasureAction, addWidgetAction, updateWidgetAction, saveModelAction). Nenhuma escrita nasce da IA.

O mesmo vale para o text-to-SQL: ele propõe apenas SELECT — nunca DML/DDL —, e você revisa antes de rodar.

2. Ações e writeback com aprovação#

Para efeitos materiais (escrever de volta num sistema, disparar uma ação), existe uma governança de aprovação com segregação de funções:

  • Quem propõe não pode aprovar a própria ação.
  • Ações de alto impacto exigem dois aprovadores distintos (aprovação dupla) — um insider ou uma conta comprometida não causa dano sozinho.
  • Fluxo de estados: pendente → aprovada → executada (com rejeitada, cancelada, falha nos desvios).
  • Idempotência: a chave é sha256(ação ‖ parâmetros canônicos) — a mesma ação com os mesmos parâmetros tem a mesma chave, e o executor nunca aplica o mesmo efeito duas vezes (os parâmetros são ordenados de forma canônica, então a ordem das chaves não muda o resultado).

Aviso

Ações/writeback são Preview e, ao contrário do que esta página já afirmou, não vêm desligadas por padrão: o interruptor ACTIONS_DISABLE só bloqueia a execução quando você o configura. Não existe liberação caso a caso pela nossa equipe. Se a postura desejada for "nada material sai daqui sem eu mandar", ligue o interruptor — não conte com um padrão conservador que não existe.

3. Trilha de auditoria da IA#

Tudo que a IA faz é registrado no registro de auditoria, escopado por workspace. Os eventos principais:

EventoO que registra
ai.reserva / ai.reserva_liquidada / ai.reserva_canceladaCiclo do orçamento (reserva → liquidação).
ai.usageCusto real (tokens × preço, em R$) + resumo de egress.
ai.blockedRecusa por teto de orçamento (custo 0) — mostra a demanda barrada.
geração assistida por IAPedido de geração assistida, tipo e se saiu como rascunho.
perguntas sobre o painel / insights do painelPerguntas de Q&A / insights, com marca de recusa/evidência fraca.

Além disso, toda resposta traz proveniencia: modelo, versão do prompt, custo real (R$) e opId — que casa ai.reserva ↔ ai.usage ↔ ai.reserva_liquidada. Isso permite correlacionar uma resposta em produção com o prompt e o custo exatos que a geraram.

4. O que NÃO é guardado#

O produto não guarda um "histórico de conversas" com a IA. O que fica é a trilha de auditoria (uso/custo/recusa) e, no relatório, os contadores de tokens no registro da execução do relatório. Ou seja: dá para auditar que houve uma chamada, seu custo e sua proveniência — sem reter um log de bate-papo.

Quem pode aprovar#

  • Confirmar artefatos de geração e publicar depende de papel de edição/publicação (ver Papéis (RBAC)).
  • 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.

Como validar#

  1. Nada publica sozinho

    Peça uma medida na geração assistida e confirme que a escrita só ocorre após a confirmação humana.

  2. Rascunho honesto

    Peça algo impossível e confirme rascunho: true com os erros listados.

  3. Segregação de funções

    Numa ação com aprovação, confirme que o propositor não consegue aprovar a própria ação.

  4. Auditoria

    Confira no registro de auditoria os eventos ai.reserva, ai.usage, ai.blocked e a proveniencia (opId) casando reserva ↔ uso.

Relacionados#


Última revisão: 2026-09-08.

Enlaces relacionados