Selo de estado:
Preview(teto atual do produto) · Curso ACD-430 — Governança de IA: custo, egress, LGPD e aprovação humana · Aula 2 de 7 · Atualizado em 2026-10-04.
Objetivo#
Ao final desta aula você vai desligar e provar o desligamento — distinguir os três níveis de corte (tudo, só as linhas, só o teto de linhas), saber qual deles é decisão de plataforma e mostrar, pelo rastro, que uma chamada de IA realmente não aconteceu.
Vídeo#
Identificador no manifesto: acd-430-02-desligar-a-ia-kill-switches · duração-alvo 5 min · tela do produto: /auditoria.
Roteiro (capítulos):
- 00:00–00:50 — Por que "desligar a IA" é ambíguo: três cortes diferentes, três efeitos diferentes.
- 00:50–02:10 — Os três controles de egress: tudo desligado · linhas desligadas (vai só resumo estatístico) · teto de linhas mais apertado (só diminui, nunca alarga).
- 02:10–03:20 — A camada de capacidades: ordem da decisão (kill global → kill por capacidade → config versionada → default exposta) e a emergência vencendo tudo.
- 03:20–04:20 — Provando o desligamento em
/auditoria: o que aparece, o que não aparece, e por que o histórico anterior continua lá. - 04:20–05:00 — Exemplo Aurora, erros comuns e o "faça você mesmo".
Conteúdo#
"Desligar a IA" são três coisas diferentes
Antes de apertar qualquer botão, saiba qual dos três cortes você quer:
| Corte | Efeito | O que ainda funciona |
|---|---|---|
| Envio a provedores desligado | Nenhuma chamada a LLM acontece, mesmo com credencial configurada. Nada sai da plataforma. | Tudo que é determinístico: anomalia, previsão, alerta, decomposição |
| Envio de linhas desligado | Linhas cruas nunca saem: no lugar delas vai um resumo estatístico por coluna (numéricas: contagem/mín/máx/soma; categóricas: contagem + nº de distintos). Nenhum valor de célula sobrevive. | As capacidades com LLM, com contexto empobrecido |
| Teto de linhas mais apertado | Reduz quantas linhas vão por widget/consulta. O valor fica entre 0 e 50 — só diminui, nunca alarga o teto atual. | Tudo, com menos contexto |
Sem nenhum ajuste, o comportamento é: até 50 linhas por bloco e chamada real ao provedor quando há credencial configurada. Ou seja: o padrão não é conservador — quem quer a postura fechada precisa ligar o corte deliberadamente.
A outra camada: capacidades
Acima do egress existe um resolvedor de capacidades, que decide se uma superfície cara ou sensível está exposta, limitada ou desligada. A ordem da decisão é fixa:
- Kill global (
*) → tudo fechado. - Kill por capacidade (
ai.sql,ai.insights, …) → aquela superfície fechada. - Config versionada (
{ v, items }) → rollout %, allowlist/denylist, override por org/workspace/usuário, validade. - Default: capacidade declarada e sem kill nasce exposta.
E, por cima de tudo, o desligamento de emergência é aplicado por último — emergência sempre vence, inclusive sobre uma config custom. Config ilegível (JSON inválido) fecha a capacidade: nunca "abre no escuro".
O padrão efetivo hoje é "exposta"
O resolvedor sabe tratar capacidade marcada como sensível — essa nasceria OFF sem decisão explícita (fail-closed) —, mas hoje nenhuma capacidade do catálogo é marcada assim, por decisão registrada no código. Então o controle vem do desligamento e dos limites, não de um baseline desligado. Não assuma que "não configurei nada" significa "está fechado".
Quem aciona, e o que você vê
O acionamento (kill, canário, rollout, emergência) é operacional/de plataforma — não é um toggle por workspace hoje. O que é visível do seu lado é o efeito: a superfície responde indisponível de forma previsível, e o resto do produto continua de pé. Na prática, no console: a pergunta de IA deixa de responder enquanto o painel, o refresh e o export seguem funcionando.
Distinga os três "nãos" que parecem iguais na tela: RBAC nega por papel (403), a verificação de conta em dia nega por inadimplência (402) e o desligamento de capacidade nega porque a superfície não está exposta — camadas ortogonais.
Em produção, um caminho que cairia em simulação falha com erro explícito em vez de fingir sucesso: sem provider de IA, a rota responde 503. Em dev/preview, o mesmo caminho cai num mock determinístico.
Exemplo: a Aurora Varejo durante uma auditoria
A Aurora Varejo vai passar por uma auditoria de dois dias e Maria (owner) quer garantir que nada saia da plataforma nessa janela. O corte certo é o primeiro — envio a provedores desligado —, acionado pela plataforma. Durante a janela, o time tenta usar a pergunta de IA sobre o painel de vendas e recebe a recusa; os relatórios agendados continuam saindo, mas sem a narrativa executiva; o alerta de meta e a anomalia diária de MEDIDA('Receita') disparam normalmente, porque nunca dependeram de LLM. Terminada a auditoria, o envio volta, e em /auditoria Maria tem o par de evidências que o exame de IA pede: eventos antes do corte, ausência de eventos novos durante, e eventos depois — com pelo menos uma recusa registrada no meio.
Erros comuns
- "Desligar a IA apaga o histórico." Não apaga nada. O desligamento impede chamadas novas; os eventos
ai.usagejá gravados continuam em/auditoriapelo prazo de retenção (730 dias para registro de auditoria). Auditoria é append-only. - Achar que desligar a IA derruba o produto. Derruba apenas as cinco capacidades com LLM. Dashboards, pipelines, export, alertas, anomalias e previsões seguem inteiros.
- Confundir desligar com "não configurar". Não configurar o corte deixa a IA ligada. O corte é opt-in.
- Achar que o teto de linhas pode ser aumentado. Não pode: o valor é limitado a [0, 50] e só aperta.
- Tratar o 503 em produção como bug. É a verdade de produção funcionando: sem provider, nada finge sucesso.
O que esta capacidade NÃO faz, e em que estado está
Não existe hoje um painel self-service por workspace para ligar e desligar egress ou capacidades — é controle de plataforma (Preview). O desligamento também não é retroativo: ele não apaga o que já foi enviado nem o rastro do que foi enviado. E ele não substitui RBAC nem a verificação de assinatura. O selo de C00.5 é Preview: o mecanismo é fail-closed e coberto por testes (incluindo a suíte adversarial anti-injeção); o que falta é o soak de IA real em produção.
Faça você mesmo#
No workspace de treino Aurora Varejo (abra /auditoria no console):
- Escreva, em uma linha cada, os três cortes de egress e o que sobra funcionando em cada um.
- Em
/auditoria, filtreai.nos últimos 7 dias e anote o último evento (data/hora, capacidade). Esse é o seu marco "antes". - Peça o desligamento do envio a provedores para a janela de treino (controle de plataforma — registre a hora de início).
- Tente fazer uma pergunta de IA sobre um painel da Aurora e copie a mensagem de recusa que aparece na tela.
- Volte a
/auditoriae confirme as duas coisas: nenhumai.usagenovo foi gravado depois do marco do passo 2, e os eventos anteriores continuam lá (desligar não apaga). - Com a IA desligada, dispare um alerta ou uma anomalia e confirme que ela funciona normalmente — prova de que o corte é cirúrgico.
- Peça o religamento, faça uma pergunta e confirme o novo
ai.usage. ⚠️ Este passo consome orçamento de IA do workspace. - Monte o "par de evidências": evento antes · recusa no meio · evento depois.
Você terminou quando tiver, em /auditoria, o par de eventos antes e depois do desligamento com ao menos uma recusa registrada entre eles, e conseguir explicar em voz alta por que o histórico anterior não desapareceu.
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#
- ai/privacidade-egress-orcamento
- administracao/capacidades-kill-switch
- administracao/suspensao
- administracao/papeis-rbac
Capacidades ensinadas#
C00.5 — o selo exibido na aula é sempre o estado mais conservador entre as capacidades citadas; nada aqui é "GA".