02 — Governança e accountability¶
Este capítulo integra a estrutura clean-room aprovada com o conteúdo substantivo do corpus autoritativo. Requisitos do framework são vendor-neutral; legislação externa, guidance, casos e histórico são identificados como tais. A implementação organizacional exige adoção formal pela authority competente e não decorre do versionamento deste repositório.
Contrato operacional do capítulo¶
As subseções seguintes formam um contrato executável de completude. Cada uma especifica a decisão ou ação requerida, o record/evidence mínimo e uma condição observável de conclusão para levar a governança do zero ao business as usual.
02.1 Design do sistema de governança¶
Decisão/ação obrigatória. Para design do sistema de governança, a organização deve selecionar e documentar a alocação centralizada, federada ou híbrida das atribuições de policy, plataforma, domínio e assurance.
Registro e evidência. Reter princípios de design, mapa de papéis, fronteiras de serviço, decision rights, handoffs, níveis de serviço e rota de exceção.
Concluído quando. Um caso representativo percorre do intake à operação sem decisão órfã nem fonte de verdade duplicada.
02.2 Modelo operacional centralizado, federado ou híbrido¶
Decisão/ação obrigatória. Para modelo operacional centralizado, federado ou híbrido, a organização deve selecionar e documentar a alocação centralizada, federada ou híbrida das atribuições de policy, plataforma, domínio e assurance.
Registro e evidência. Reter princípios de design, mapa de papéis, fronteiras de serviço, decision rights, handoffs, níveis de serviço e rota de exceção.
Concluído quando. Um caso representativo percorre do intake à operação sem decisão órfã nem fonte de verdade duplicada.
02.3 Accountability executiva¶
Decisão/ação obrigatória. Para accountability executiva, a organização deve atribuir ao papel nomeado um resultado accountable, autoridade explícita e decisões indelegáveis.
Registro e evidência. O RACI e o charter do papel devem declarar deveres, evidências exigidas, handoffs, escalonamento, regras de delegação e competência.
Concluído quando. O papel aceita um registro representativo e a accountability permanece clara quando a entrega é delegada a outro time ou fornecedor.
02.4 Governance owner¶
Decisão/ação obrigatória. Para governance owner, a organização deve atribuir ao papel nomeado um resultado accountable, autoridade explícita e decisões indelegáveis.
Registro e evidência. O RACI e o charter do papel devem declarar deveres, evidências exigidas, handoffs, escalonamento, regras de delegação e competência.
Concluído quando. O papel aceita um registro representativo e a accountability permanece clara quando a entrega é delegada a outro time ou fornecedor.
02.5 Business ownership¶
Decisão/ação obrigatória. Para business ownership, a organização deve atribuir ao papel nomeado um resultado accountable, autoridade explícita e decisões indelegáveis.
Registro e evidência. O RACI e o charter do papel devem declarar deveres, evidências exigidas, handoffs, escalonamento, regras de delegação e competência.
Concluído quando. O papel aceita um registro representativo e a accountability permanece clara quando a entrega é delegada a outro time ou fornecedor.
02.6 Technical ownership¶
Decisão/ação obrigatória. Para technical ownership, a organização deve atribuir ao papel nomeado um resultado accountable, autoridade explícita e decisões indelegáveis.
Registro e evidência. O RACI e o charter do papel devem declarar deveres, evidências exigidas, handoffs, escalonamento, regras de delegação e competência.
Concluído quando. O papel aceita um registro representativo e a accountability permanece clara quando a entrega é delegada a outro time ou fornecedor.
02.7 Product ownership¶
Decisão/ação obrigatória. Para product ownership, a organização deve atribuir ao papel nomeado um resultado accountable, autoridade explícita e decisões indelegáveis.
Registro e evidência. O RACI e o charter do papel devem declarar deveres, evidências exigidas, handoffs, escalonamento, regras de delegação e competência.
Concluído quando. O papel aceita um registro representativo e a accountability permanece clara quando a entrega é delegada a outro time ou fornecedor.
02.8 Responsabilidades de gestão de risco¶
Decisão/ação obrigatória. Para responsabilidades de gestão de risco, a organização deve atribuir ao papel nomeado um resultado accountable, autoridade explícita e decisões indelegáveis.
Registro e evidência. O RACI e o charter do papel devem declarar deveres, evidências exigidas, handoffs, escalonamento, regras de delegação e competência.
Concluído quando. O papel aceita um registro representativo e a accountability permanece clara quando a entrega é delegada a outro time ou fornecedor.
02.9 Responsabilidades legais e regulatórias¶
Decisão/ação obrigatória. Para responsabilidades legais e regulatórias, a organização deve atribuir ao papel nomeado um resultado accountable, autoridade explícita e decisões indelegáveis.
Registro e evidência. O RACI e o charter do papel devem declarar deveres, evidências exigidas, handoffs, escalonamento, regras de delegação e competência.
Concluído quando. O papel aceita um registro representativo e a accountability permanece clara quando a entrega é delegada a outro time ou fornecedor.
02.10 Responsabilidades de privacidade e proteção de dados¶
Decisão/ação obrigatória. Para responsabilidades de privacidade e proteção de dados, a organização deve atribuir ao papel nomeado um resultado accountable, autoridade explícita e decisões indelegáveis.
Registro e evidência. O RACI e o charter do papel devem declarar deveres, evidências exigidas, handoffs, escalonamento, regras de delegação e competência.
Concluído quando. O papel aceita um registro representativo e a accountability permanece clara quando a entrega é delegada a outro time ou fornecedor.
02.11 Responsabilidades de segurança da informação¶
Decisão/ação obrigatória. Para responsabilidades de segurança da informação, a organização deve atribuir ao papel nomeado um resultado accountable, autoridade explícita e decisões indelegáveis.
Registro e evidência. O RACI e o charter do papel devem declarar deveres, evidências exigidas, handoffs, escalonamento, regras de delegação e competência.
Concluído quando. O papel aceita um registro representativo e a accountability permanece clara quando a entrega é delegada a outro time ou fornecedor.
02.12 Responsabilidades de governança de dados¶
Decisão/ação obrigatória. Para responsabilidades de governança de dados, a organização deve atribuir ao papel nomeado um resultado accountable, autoridade explícita e decisões indelegáveis.
Registro e evidência. O RACI e o charter do papel devem declarar deveres, evidências exigidas, handoffs, escalonamento, regras de delegação e competência.
Concluído quando. O papel aceita um registro representativo e a accountability permanece clara quando a entrega é delegada a outro time ou fornecedor.
02.13 Responsabilidades de IA responsável¶
Decisão/ação obrigatória. Para responsabilidades de IA responsável, a organização deve atribuir ao papel nomeado um resultado accountable, autoridade explícita e decisões indelegáveis.
Registro e evidência. O RACI e o charter do papel devem declarar deveres, evidências exigidas, handoffs, escalonamento, regras de delegação e competência.
Concluído quando. O papel aceita um registro representativo e a accountability permanece clara quando a entrega é delegada a outro time ou fornecedor.
02.14 Responsabilidades de operações, SRE, SOC e suporte¶
Decisão/ação obrigatória. Para responsabilidades de operações, SRE, SOC e suporte, a organização deve atribuir ao papel nomeado um resultado accountable, autoridade explícita e decisões indelegáveis.
Registro e evidência. O RACI e o charter do papel devem declarar deveres, evidências exigidas, handoffs, escalonamento, regras de delegação e competência.
Concluído quando. O papel aceita um registro representativo e a accountability permanece clara quando a entrega é delegada a outro time ou fornecedor.
02.15 Auditoria interna e challenge independente¶
Decisão/ação obrigatória. Para auditoria interna e challenge independente, a organização deve definir escopo do challenge e critérios de independência antes de o revisor avaliar o trabalho.
Registro e evidência. Registrar linha de reporte, conflitos, serviços incompatíveis, população, amostra, critérios, limitações e forma da conclusão.
Concluído quando. O revisor não conclui sobre trabalho que ele mesmo desenhou ou operou, e as alegações não excedem o escopo e a evidência aprovados.
02.16 Fóruns de governança e termos de referência¶
Decisão/ação obrigatória. Para fóruns de governança e termos de referência, a organização deve constituir cada fórum com as decisões que pode tomar, quórum, composição, entradas, saídas e escalonamento.
Registro e evidência. Reter termos de referência, pauta, registro de decisões, conflitos, presença, condições e owners das ações.
Concluído quando. Resultados do fórum são exequíveis e não substituem discussão por uma decisão accountable nomeada.
02.17 Decision rights por evento de lifecycle¶
Decisão/ação obrigatória. Para decision rights por evento de lifecycle, a organização deve mapear cada evento material de lifecycle e severidade de incidente para uma decisão accountable e um caminho de escalonamento.
Registro e evidência. Registrar evento, threshold, autoridade primária e alternativa, consulta, tempo de resposta e fallback para decisão não resolvida.
Concluído quando. Um exercício (drill) alcança uma decisão autorizada dentro do alvo e autoridade ambígua falha para o estado mais seguro.
02.18 Caminhos de escalonamento¶
Decisão/ação obrigatória. Para caminhos de escalonamento, a organização deve mapear cada evento material de lifecycle e severidade de incidente para uma decisão accountable e um caminho de escalonamento.
Registro e evidência. Registrar evento, threshold, autoridade primária e alternativa, consulta, tempo de resposta e fallback para decisão não resolvida.
Concluído quando. Um exercício (drill) alcança uma decisão autorizada dentro do alvo e autoridade ambígua falha para o estado mais seguro.
02.19 Segregação de funções e conflitos de interesse¶
Decisão/ação obrigatória. Para segregação de funções e conflitos de interesse, a organização deve separar construção, operação, aprovação e assurance onde a auto-revisão criaria viés material.
Registro e evidência. Registrar deveres incompatíveis, declarações de conflito, separação técnica, impedimento (recusal) e revisão compensatória.
Concluído quando. Nenhuma pessoa pode criar e aprovar independentemente a mesma evidência material sem exceção autorizada.
02.20 Hierarquia de policy e padrões locais¶
Decisão/ação obrigatória. Para hierarquia de policy e padrões locais, a organização deve mapear este framework para políticas superiores, padrões subordinados e procedimentos locais sem criar uma segunda fonte canônica.
Registro e evidência. Registrar tipo de relacionamento, owner, versão, regra de conflito e o requisito ou decisão exata vinculada.
Concluído quando. Um conflito resolve-se por regra de precedência aprovada e artefatos a jusante podem ser avaliados por impacto em caso de mudança.
02.21 Processo de exceção, waiver e risk acceptance¶
Decisão/ação obrigatória. Para processo de exceção, waiver e risk acceptance, a organização deve permitir exceções somente para requisito, período e ativo delimitados após avaliação de alternativas.
Registro e evidência. Registrar requisito, escopo, rationale, compensating controls, owner, risco residual, aprovador, expiração e gatilho de revisão.
Concluído quando. Exceções expiradas bloqueiam a continuidade da dependência e uma exceção nunca sobrepõe um uso proibido por lei ou por policy.
02.22 Requisitos de competência¶
Decisão/ação obrigatória. Para requisitos de competência, a organização deve definir competências e treinamentos específicos por papel, vinculados a decisões e tarefas, em vez de conscientização genérica.
Registro e evidência. Registrar papel, objetivo de aprendizado, método de avaliação, conclusão, expiração, remediação e owner da evidência.
Concluído quando. Pessoal demonstra a tarefa ou decisão exigida e competência vencida é visível antes de acesso ou autoridade ser exercido.
02.23 Treinamento baseado em papel¶
Decisão/ação obrigatória. Para treinamento baseado em papel, a organização deve definir competências e treinamentos específicos por papel, vinculados a decisões e tarefas, em vez de conscientização genérica.
Registro e evidência. Registrar papel, objetivo de aprendizado, método de avaliação, conclusão, expiração, remediação e owner da evidência.
Concluído quando. Pessoal demonstra a tarefa ou decisão exigida e competência vencida é visível antes de acesso ou autoridade ser exercido.
02.24 Comunicação e conscientização internas¶
Decisão/ação obrigatória. Para comunicação e conscientização internas, a organização deve prover rotas de comunicação, suporte e feedback adequadas ao papel antes e durante o rollout.
Registro e evidência. Registrar público, mensagem, canal, momento, owner, sinal de compreensão, feedback e ação resultante.
Concluído quando. Usuários afetados conhecem a fronteira do sistema, a rota de reporte e a consequência do uso indevido, e o feedback chega a um owner accountable.
02.25 Revisão e mudança de documentos de governança¶
Decisão/ação obrigatória. Para revisão e mudança de documentos de governança, a organização deve encaminhar mudanças materiais por análise de impacto, consulta às funções afetadas e aprovação.
Registro e evidência. Reter proposta, rationale, papéis consultados, objeções, resultado de compatibilidade, decisão e plano de migração.
Concluído quando. Decisões aceitas são superseded em vez de reescritas silenciosamente e dependentes afetados recebem atualização rastreável.
Conteúdo canônico incorporado¶
A seção preserva integralmente as unidades atribuídas pela matriz de cobertura. Os marcadores HTML são provenance machine-readable e não alteram o significado normativo.
Fonte: docs/governance/ai-agent-policy-and-governance-v1.md¶
Commit de origem: 5545d9227624400ab8bb707b6032b2f61329a36e.
4. Governance Model (Design/Run/Human Accountability)¶
4.4 Right to Create and Publish (Create vs Promote to Prod)¶
Creation (Test/PoC): allowed only on approved platforms and in non-production environments. Requires a completed Self-Assessment and designated Owners (Business Owner and Technical Owner) before first use. The creator must have a formally granted license and access profile (Agent Creator role), with minimum training and acceptance of the usage rules. Publication/Promotion to Production: only after approval according to the Approval Matrix, registration in the Catalog, and completion of the Publication Checklist. Promotion to Production must be performed by an Agent Publisher profile (Run Authority or formally delegated), ensuring segregation of duties when applicable (SOX/ITGC). Granting of accesses and permissions: requested by the Business Owner; validated by the Technical Owner; approved by the Data Owner/DPO when involving personal/sensitive data and by Cyber/ITGC when involving critical systems. Run Authority implements and maintains evidence (RBAC/ABAC, audit trails). Access review: periodic reviews (e.g., semiannual) for agents in Production and whenever there is a change in scope, data, integrations, or level of autonomy.
4.5 Representation Rule in the Organizational Chart (when applicable)¶
AI agents are not positions (FTE) on the organizational chart; they are digital capabilities linked to a business domain, with explicit human accountability. An agent must be indicated in the detailed organizational chart (or capabilities catalog) when it meets at least one criterion: Use in Production with >100 users; or Execution of a critical process (operational, financial, security, quality) or subject to SOX/ITGC; or Official corporate channel (broad interaction with employees) or interface with external public; or Autonomy level L2 or higher (see section 8.1). The representation must reference: agent name, domain/area, Business Owner, Technical Owner, responsible Run Authority, and link/ID in the Catalog.
4.5 AI Governance Awareness¶
All employees authorized to create, publish, or operate AI agents must complete corporate AI Governance training before access is granted and undergo annual refresher training. The minimum content covers: principles of responsible AI, risk assessment (blast radius), levels of autonomy and HITL, data protection (applicable data protection law (e.g., GDPR/LGPD)), security and proper use of logs and kill switch.
15. RACI (Roles and Responsibilities)¶
Agents create new types of responsibility: it is not enough for "IT to approve" or "business to request." This section defines clear roles and responsibilities (RACI) to ensure consistent decision-making, secure operation, and human accountability by agent, separating policy design functions (Design Authority), operation and technical controls (Run Authority), and nominative responsibility (Business Owner and Technical Owner). The goal is to avoid gaps ("no one owns it"), conflicts ("two areas decide differently"), and segregation risks (SOX/ITGC), making governance executable at any level of the organization. Design Authority: Responsible/Accountable for policies and standards; Consulted for segments; Informed by Run. Run Authority: Responsible for operation and observability; Accountable for incidents; Consulted for Design; Informed for owners. Business Owner (by agent): Accountable for value/risk/budget; Responsible for requirements; Consulted for compliance; Informed for Run; Review the agent's value and risk quarterly and decide on continuity, adjustment, or sunset. Technical Owner (by agent): Responsible for integrations and security; Accountable for permissions; Responsible for quarterly review of technical performance, security, logs, and access controls. Legend R = Responsible (executes the activity) A = Accountable (owns the decision and outcome) C = Consulted (provides input) I = Informed (kept informed) Notes Cells show A / R where the context indicated both accountability and responsibility. Business Owner leads value/risk decisions and requirements; Technical Owner leads technical integrations, security, permissions, and technical reviews; Run Authority leads operations and incident response; Design Authority defines policies and is consulted on segments and design.
Fonte: docs/governance/operating-model.md¶
Commit de origem: 5545d9227624400ab8bb707b6032b2f61329a36e.
Título controlado na origem: Operating model e decision rights
Operating model e decision rights¶
Objetivo¶
Converter os princípios da policy modular em decisões executáveis, com autoridade, handoffs, evidências e tempos de resposta definidos. Sua adoção organizacional depende de release e authority explícitas.
Modelo federado¶
Governança é coordenada e distribuída. Um council comum define risk appetite, padrões mínimos e exceções; autoridades de domínio preservam suas competências e evidências.
flowchart TB
SP[Executive Sponsor]
GC[AI Governance Council]
DA[Design Authority]
RA[Run Authority]
BO[Business Owner]
TO[Technical Owner]
DOM[Identity • Data • Security • Privacy • Legal • RAI]
AS[Assurance / Challenge]
SP --> GC
GC --> DA
GC --> RA
BO --> DA
TO --> DA
DOM --> DA
DA -->|release evidence| RA
RA -->|runtime evidence| GC
AS -. verifica .-> GC
AS -. verifica .-> DA
AS -. verifica .-> RA
Papéis¶
Executive Sponsor¶
- garante mandato, funding e alinhamento estratégico;
- aprova risk appetite e conflitos de prioridade;
- remove impedimentos que excedem authority operacional;
- não substitui owners nas decisões técnicas.
AI Governance Council¶
- mantém policy, taxonomia, tiers e critérios comuns;
- resolve conflitos entre domínios;
- aprova exceções materiais e mudanças de risk appetite;
- revisa portfólio, incidentes sistêmicos e value evidence.
Design Authority¶
- avalia blueprint, risco, arquitetura e release evidence;
- coordena identity, data, security, privacy e RAI;
- decide ou recomenda publicação conforme tier;
- devolve gaps com owner e critério de aceite.
Run Authority¶
- define observabilidade, incidentes, quarantine e reactivation;
- pode conter agentes quando sinais ultrapassam limites aprovados;
- mantém escalations, SLOs e drills;
- não altera finalidade ou risco aceito sem voltar à Design Authority.
Business Owner¶
- responde por finalidade, usuários, outcome e impacto;
- aceita residual risk quando autorizado;
- revisa valor, qualidade e continuidade;
- garante comunicação com pessoas afetadas.
Technical Owner¶
- responde por blueprint, implementação, dependências e operações técnicas;
- mantém controls, evals, runbooks e evidências;
- comunica mudanças materiais;
- executa correção, rollback e sunset técnico.
Domain Authorities¶
| Domínio | Authority primária |
|---|---|
| identidade | padrões de workload identity, autenticação e autorização |
| dados | classificação, finalidade, lineage, minimização e connector gates |
| segurança | threat model, security testing, monitoramento e resposta |
| privacy | DPIA/triggers, direitos, retenção e tratamento de dados pessoais |
| jurídico/compliance | obrigações, uso aceitável, contratos e restrições setoriais |
| Responsible AI | impacto, fairness, transparência, safety e human oversight |
| plataforma | capabilities, enforcement points, adapters e service health |
Assurance / Challenge¶
- verifica design e operação sem assumir ownership da decisão;
- testa suficiência e integridade das evidências;
- registra findings, severity, divergência e prazo;
- não transforma ausência de finding em garantia absoluta.
Há três níveis distintos: self-check do control owner, peer challenge separado do build e independent assurance. Independent é uma propriedade do arrangement, não do nome do papel. Exige, no mínimo:
- ausência de responsabilidade por design, implementação e operação do objeto revisado;
- conflitos e serviços anteriores declarados e avaliados;
- reporting line e authority para publicar findings sem interferência;
- scope, criteria, population, sampling e evidence cutoff definidos;
- método, forma da conclusão, limitações, remediação e renewal aprovados.
Quando esses requisitos não estiverem demonstrados, use peer challenge ou limited-scope review. O mesmo fornecedor que diagnosticou, desenhou ou implementou não pode emitir independent assurance sobre o próprio trabalho sem uma regra institucional explícita de serviços incompatíveis e safeguards; este framework não presume que tais safeguards existam.
Decision rights¶
| Decisão | Accountable | Consultados | Evidência mínima |
|---|---|---|---|
| aprovar propósito e baseline | Business Owner | Sponsor, Finance, usuários | business case e baseline |
| classificar tier de risco | Design Authority | Risk, RAI, Security, Data | registry, blueprint e assessment |
| conceder identidade/acesso | Domain Authority | Technical Owner | least-privilege mapping e expiry |
| aprovar tool ou MCP server | Tool Authority | Security, Data, Platform | provenance, scopes, threat model e kill switch |
| liberar para produção | Design/Release Authority | Owners e domínios aplicáveis | release package completo |
| conter ou quarentenar | Run Authority | Business/Technical Owner | signal, severity, scope e timestamp |
| reativar | Run + Design Authority | Domain Authorities | causa, correção e regression evidence |
| aceitar risco residual | Authority definida por tier | Legal, RAI, Security, negócio | residual risk, prazo e compensating controls |
| aprovar exceção | Governance Council ou delegado | owners afetados | rationale, owner, expiry e review |
| aposentar | Business Owner | Technical Owner, Run Authority | usage/value review, retention e sunset plan |
Fóruns e cadência¶
| Fórum | Cadência sugerida | Saída |
|---|---|---|
| portfolio review | mensal ou trimestral | priorização, funding, duplicidade e sunset |
| design review | por mudança material | decisão, conditions e evidence gaps |
| runtime risk review | semanal ou por severidade | incidentes, quarantine, trends e remediation |
| control owner review | mensal | eficácia, exceções, SLA e automação |
| attestation | por tier, no máximo anual | reconfirmação ou retirada de aprovação |
| policy review | anual ou evento material | versão, rationale e migration plan |
Cadências são adaptadas ao contexto; eventos críticos ignoram o calendário e seguem incident response.
Handoffs obrigatórios¶
- Estratégia → design: propósito, owner, usuários, baseline e constraints.
- Design → assurance/challenge: blueprint, dados, identidade, tools, risk tier e test plan.
- Assurance/challenge → release: findings, residual risk, approvals e expiry.
- Release → run: thresholds, telemetry, runbooks, quarantine e support owner.
- Run → governance: incidentes, exceptions, value evidence e mudanças materiais.
- Governance → sunset: decisão, retenção, comunicação, revogação e archive.
Um handoff sem owner receptor e evidência não está concluído.
Segregation of duties por tier¶
| Tier | Separação mínima |
|---|---|
| T1 — baixo | technical owner pode executar; business owner aprova propósito |
| T2 — moderado | peer reviewer separado da execução de build valida release evidence |
| T3 — alto | Design Authority e domain authorities aplicáveis aprovam; conflitos são declarados |
| T4 — crítico | aprovação executiva ou comitê, challenge com segregation formal e runtime oversight contínuo; usar independent assurance somente se os requisitos acima forem demonstrados |
Exceções¶
Toda exceção contém:
- requisito afetado;
- justificativa e impacto;
- owner nominativo;
- compensating controls;
- data de expiração;
- gatilho de revisão antecipada;
- plano de regularização ou sunset.
Exceção sem expiração é alteração de policy disfarçada.
Métricas do operating model¶
- decisões dentro do SLA por tier;
- evidence packages devolvidos por falta de completude;
- exceções abertas, expiradas e reincidentes;
- tempo entre signal, decisão e contenção;
- porcentagem de agentes com owners e attestation válidos;
- findings por control domain e tempo de remediação;
- mudanças materiais não declaradas;
- decisões de manter, corrigir, restringir ou aposentar.
As métricas medem fluxo e controle; não substituem outcomes de negócio ou impacto responsável.
Antiobjetivos¶
- criar um “time de governança” que absorve ownership dos demais;
- exigir o mesmo processo para todo risco;
- automatizar approvals antes de estabilizar policy e exceções;
- usar council como fila operacional;
- tratar registro, dashboard ou assinatura como prova isolada de eficácia.
Fonte: docs/human-oversight/README.md¶
Commit de origem: 5545d9227624400ab8bb707b6032b2f61329a36e.
Título controlado na origem: Human oversight e accountability
Human oversight e accountability¶
Objetivo¶
Projetar supervisão humana com autoridade, informação, tempo e competência suficientes para prevenir, detectar, interromper ou corrigir efeitos inadequados.
AI-operated, human-led¶
Um humano “no loop” não garante controle. Oversight efetivo exige:
- decision right explícito;
- visibilidade do que o agente pretende fazer;
- informação sobre risco e incerteza;
- capacidade técnica de bloquear ou reverter;
- tempo compatível com a decisão;
- competência e independência;
- registro de decisão e resultado.
Modos de supervisão¶
| Modo | Descrição | Uso |
|---|---|---|
| human-in-command | humano define finalidade, limites e autoridade | todos os tiers |
| human-in-the-loop | aprovação antes da ação | ação material ou irreversível |
| human-on-the-loop | monitoramento e intervenção durante operação | volume alto com contenção rápida |
| human-out-of-the-loop | sem revisão por execução | somente escopo aprovado, reversível e observado |
O modo é escolhido por risco e capability, não por preferência de UX.
Accountability boundary¶
Para cada decisão, registrar:
- o que o agente pode decidir;
- o que apenas prepara ou recomenda;
- o que exige aprovação humana;
- o que é proibido;
- qual humano ou função é accountable;
- quando escalonar;
- como interromper e reverter;
- como contestar e corrigir.
Approval UX¶
Uma confirmação de alto impacto deve mostrar:
- ação e alvo;
- dados ou sistemas afetados;
- consequência esperada;
- irreversibilidade e rollback;
- evidência ou rationale do agente;
- alertas e policy conditions;
- opção clara de negar ou editar;
- identity de quem aprova.
Botão genérico “OK” sem contexto não constitui informed approval.
Quando exigir aprovação¶
Triggers incluem:
- delete, payment, approval ou privileged change;
- decisão sobre emprego, crédito, saúde, segurança ou direito;
- comunicação pública ou em nome da organização;
- acesso/transferência de dado sensível;
- code execution em ambiente relevante;
- mudança de policy, identidade ou permissão;
- ação sem rollback confiável;
- confiança ou evidência abaixo do threshold.
Evitar rubber stamping¶
- reduzir volume de approvals por melhor tiering, não por remover controle;
- agrupar apenas ações homogêneas e reversíveis;
- mostrar diferenças e exceções;
- medir tempo, override e concordância automática;
- rotacionar reviewer em atividades repetitivas;
- permitir amostragem para baixo risco e revisão total para red flags;
- treinar reviewers sobre failure modes.
Escalation e break-glass¶
Break-glass exige:
- condição de uso definida;
- identidade forte e authority;
- privilege temporário;
- registro e alerta imediato;
- limitação de escopo;
- revisão posterior obrigatória;
- revogação automática.
Urgência não transforma ação desconhecida em baixo risco.
Contestability e redress¶
Pessoas afetadas devem ter, quando aplicável:
- canal acessível;
- identificação do decision owner;
- revisão humana significativa;
- correção de dados ou resultado;
- prazo e comunicação;
- registro para análise sistêmica.
Evidências¶
- accountability matrix;
- approval rules e screenshots/UX specs;
- logs de approve, deny, edit e override;
- training/competence records;
- break-glass logs;
- contest e redress records;
- drill de kill switch ou rollback;
- review de automation bias.
Métricas¶
- approval rate e override rate;
- tempo de decisão por tier;
- ações executadas sem authority correta;
- rubber-stamp indicators;
- break-glass frequency e findings;
- contest volume e correction time;
- failed rollback/kill-switch drills;
- decisões sem rationale recuperável.
Failure modes¶
- humano sem autoridade real;
- aprovação depois da ação;
- reviewer sem informação ou tempo;
- confirmação escondida em termos genéricos;
- exigir approval em excesso e induzir fadiga;
- não registrar edits e overrides;
- accountability atribuída a “o time”;
- break-glass permanente.
Decision gate¶
A release authority verifica se o oversight mode, approval UX, escalation, contestability e rollback correspondem ao tier e às ações possíveis.
Acceptance criteria¶
- todas as decisões deste capítulo possuem authority, owner e evidência recuperável;
- requisitos aplicáveis estão ligados ao catálogo de controles e ao método de verificação;
- exceções têm escopo, justificativa, compensating controls, expiry e decisão residual;
- controles de build time e runtime são distinguidos e exercitados quando aplicáveis;
- mudanças materiais reabrem avaliação, aprovação e evidência;
- nenhuma alegação de conformidade, eficácia ou valor excede a evidência observada.