00 — Controle do documento¶

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.

00.1 Identificação e finalidade¶

Decisão/ação obrigatória. Para identificação e finalidade, a organização deve atribuir um identificador de documento estável e declarar o problema de decisão, o público e o uso pretendido.

Registro e evidência. Registrar identificador, título, finalidade, público, status normativo e localização no repositório no controle do documento.

Concluído quando. Um leitor consegue distinguir este framework, seus produtos dependentes e seus não-objetivos sem depender de conhecimento tribal.

00.2 Owner do documento e autoridade responsável¶

Decisão/ação obrigatória. Para owner do documento e autoridade responsável, a organização deve nomear uma autoridade responsável e um custodiano operacional para o documento.

Registro e evidência. Registrar papel, delegado nomeado quando aplicável, fonte de autoridade, rota de contato e regra de sucessão.

Concluído quando. Aprovação, interpretação, revisão programada e mudança emergencial têm cada uma um tomador de decisão inequívoco.

00.3 Status de aprovação e força normativa¶

Decisão/ação obrigatória. Para status de aprovação e força normativa, a organização deve declarar se o artefato é draft, aprovado, histórico, informativo ou descontinuado e o que esse status permite.

Registro e evidência. Reter decisão de aprovação, aprovador, data, condições, data de efetividade e evidência de adoção.

Concluído quando. Nenhum draft, estudo de caso ou fonte histórica pode ser confundido com um requisito organizacional vigente.

00.4 Versão, data de efetividade e ciclo de revisão¶

Decisão/ação obrigatória. Para versão, data de efetividade e ciclo de revisão, a organização deve versionar toda mudança material e vinculá-la a datas de efetividade, revisão e supersessão.

Registro e evidência. Reter descrição da mudança, autor, aprovador, contratos impactados, ação de migração e referência à versão anterior.

Concluído quando. Consumidores identificam a versão aplicável e registros incompatíveis são migrados, rejeitados ou explicitamente grandfather.

00.5 Escopo de aplicação¶

Decisão/ação obrigatória. Para escopo de aplicação, a organização deve enumerar inclusões, exclusões, jurisdições, estágios de lifecycle, unidades organizacionais e classes de stakeholders afetados.

Registro e evidência. Reter declaração de escopo com rationale de fronteira, obrigações externas, padrões locais delegados e expiração de exclusões.

Concluído quando. O intake consegue encaminhar cada candidato como dentro do escopo, fora do escopo ou exigindo decisão, sem isenção implícita.

00.6 Políticas, padrões e registros relacionados¶

Decisão/ação obrigatória. Para políticas, padrões e registros relacionados, 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.

00.7 Processo de mudança, consulta e aprovação¶

Decisão/ação obrigatória. Para processo de mudança, consulta e aprovação, 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.

00.8 Distribuição, acesso e retenção¶

Decisão/ação obrigatória. Para distribuição, acesso e retenção, a organização deve definir quem pode ler, alterar e recuperar o registro, por quanto tempo e sob qual regra de legal hold ou exclusão.

Registro e evidência. Registrar classificação, grupos de acesso, custodiano, gatilho de retenção, período mínimo, disposição e caminho de recuperação de auditoria.

Concluído quando. Evidências autorizadas são recuperáveis no prazo exigido e dados expirados são descartados sem romper a linhagem exigida.

00.9 Interpretação e resolução de conflitos¶

Decisão/ação obrigatória. Para interpretação e resolução de conflitos, a organização deve definir a autoridade e a rota de escalonamento para requisitos ambíguos, conflitantes ou localmente inaplicáveis.

Registro e evidência. Reter pergunta, interpretações concorrentes, autoridades consultadas, restrição provisória e disposição final.

Concluído quando. Times de entrega não resolvem ambiguidade material por conveniência e a decisão é propagada aos registros afetados.

00.10 Histórico de revisões¶

Decisão/ação obrigatória. Para histórico de revisões, a organização deve versionar toda mudança material e vinculá-la a datas de efetividade, revisão e supersessão.

Registro e evidência. Reter descrição da mudança, autor, aprovador, contratos impactados, ação de migração e referência à versão anterior.

Concluído quando. Consumidores identificam a versão aplicável e registros incompatíveis são migrados, rejeitados ou explicitamente grandfather.

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/policy.md`¶

Commit de origem: 5545d9227624400ab8bb707b6032b2f61329a36e.

Título controlado na origem: AI Agent Governance Policy — fonte canônica modular

AI Agent Governance Policy — fonte canônica modular¶

Propósito¶

Este repositório é a fonte modular a partir da qual a policy final de governança de IA e agentes será mantida, revisada e versionada. A policy não é um documento monolítico nem depende de uma plataforma específica: ela é composta por princípios, decision rights, requisitos, controls, evidências e regras de lifecycle distribuídos em módulos canônicos.

Dois níveis de adoção¶

A release 1.0 deste framework está adopted desde 2026-08-10, conforme a ADR-0006. Isso significa que esta versão é a baseline canônica estável e que mudança normativa passa a exigir proposta, rationale, authority, changelog e release versionada.

Isso não significa que qualquer organização adotou esta policy. A adoção organizacional é uma decisão separada: cada organização declara esta baseline como sua policy interna pela sua própria authority competente, com escopo, exceções e obrigações próprias. Enquanto essa decisão não existir, o conteúdo é referência técnica canônica do framework — não a policy vigente daquela organização.

Confundir os dois níveis transforma versionamento em declaração de conformidade. Nenhum claim de certificação, auditoria independente ou conformidade decorre da adoção da release.

Composição da policy¶

A policy canônica deste framework é formada por:

princípios arquiteturais;
operating model e decision rights;
arquitetura em cinco planos;
gestão proporcional de riscos;
domínios canônicos de identidade, dados, tools, segurança, Responsible AI, oversight, evaluations, auditabilidade, operações, adoção e valor;
control catalog;
implementation playbook e decision gates;
schemas e evidence packages que tornam os requisitos verificáveis.

O handbook define a ordem editorial desses módulos, sem duplicá-los.

Conteúdo não normativo¶

Não integram a policy, salvo incorporação explícita e versionada:

estudos de caso e explicações em docs/explanations/;
crosswalks e avaliações comparativas em assessments/;
fontes e referências externas em references/;
exemplos fictícios em examples/;
roadmap, specs e experimentos;
calendários de 90 dias/24 semanas e o plano opcional de piloto;
mappings de fornecedores.

Esses artefatos podem informar decisões, mas não criam dependência tecnológica nem requisito normativo por associação.

Neutralidade de fornecedor¶

A policy define capabilities, outcomes, controls, evidências e boundaries, não produtos obrigatórios. Fornecedores e plataformas nomeados podem aparecer como fonte, caso observado ou mapping opcional. Nenhum deles é componente necessário do framework ou condição para conformidade com a policy.

Um mapping deve poder ser removido sem alterar princípios, controls, decision gates, schemas ou a arquitetura canônica.

Evolução e versionamento¶

Mudanças normativas devem:

declarar o requisito alterado e sua justificativa;
registrar decisão e authority;
atualizar controls, evidências e impactos operacionais;
preservar versões anteriores;
incluir changelog e migration guidance quando necessário;
passar pelos quality gates do repositório antes de release.

Origem histórica¶

A AI Agent Policy and Governance v1 foi o ponto inicial deste trabalho. Ela é preservada byte a byte para rastreabilidade histórica, mas não é usada como fonte normativa recorrente do framework modular.

O guia externo "Governança de Agentes de IA em Escala", mantido anteriormente como documento independente, também é origem histórica. Seu conteúdo procedural foi absorvido por este repositório conforme a ADR-0003, reescrito no formato canônico. Cópias daquele documento não são normativas e podem conter taxonomia divergente: a conversão para T1–T4 e a separação de Restricted como admissibilidade seguem a ADR-0009.

Este repositório é a fonte única e final. Qualquer publicação em outro formato deve ser derivada destes módulos, nunca mantida como cópia editorial independente.

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.