Pular para o conteúdo

Kill switch do envio externo

Aula 2 de 75 minOperarAtualizada em 2026-10-04

Vídeo em produção

A gravação desta aula está no lote de produção. O objetivo, o exercício e a documentação já valem. Duração-alvo: 5 min.

Objetivo: Desligar e provar o desligamento

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):

  1. 00:00–00:50 — Por que "desligar a IA" é ambíguo: três cortes diferentes, três efeitos diferentes.
  2. 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).
  3. 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.
  4. 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á.
  5. 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:

CorteEfeitoO que ainda funciona
Envio a provedores desligadoNenhuma 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 desligadoLinhas 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 apertadoReduz 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:

  1. Kill global (*) → tudo fechado.
  2. Kill por capacidade (ai.sql, ai.insights, …) → aquela superfície fechada.
  3. Config versionada ({ v, items }) → rollout %, allowlist/denylist, override por org/workspace/usuário, validade.
  4. 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.usage já gravados continuam em /auditoria pelo 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):

  1. Escreva, em uma linha cada, os três cortes de egress e o que sobra funcionando em cada um.
  2. Em /auditoria, filtre ai. nos últimos 7 dias e anote o último evento (data/hora, capacidade). Esse é o seu marco "antes".
  3. Peça o desligamento do envio a provedores para a janela de treino (controle de plataforma — registre a hora de início).
  4. Tente fazer uma pergunta de IA sobre um painel da Aurora e copie a mensagem de recusa que aparece na tela.
  5. Volte a /auditoria e confirme as duas coisas: nenhum ai.usage novo foi gravado depois do marco do passo 2, e os eventos anteriores continuam lá (desligar não apaga).
  6. Com a IA desligada, dispare um alerta ou uma anomalia e confirme que ela funciona normalmente — prova de que o corte é cirúrgico.
  7. Peça o religamento, faça uma pergunta e confirme o novo ai.usage. ⚠️ Este passo consome orçamento de IA do workspace.
  8. 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#

Capacidades ensinadas#

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

Carregando seu progresso…