08 — Implementação e adoção

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.

08.1 Princípios de implementação

Decisão/ação obrigatória. Para princípios de implementação, a organização deve entregar esta capacidade de implementação como workstream com owner, dependências e critérios de saída.

Registro e evidência. O plano de implementação deve registrar baseline, alvo, owner, recursos, sequência, evidência de aceite, riscos, dependências e destinatário do handoff.

Concluído quando. A capacidade funciona em um caminho representativo, usuários e operadores conseguem executá-la, e o ownership permanente aceita o runbook e o backlog.

08.2 Diagnóstico do estado atual

Decisão/ação obrigatória. Para diagnóstico do estado atual, a organização deve estabelecer um baseline datado de ativos, capacidades, owners, controles, evidências e dores operacionais antes de desenhar o estado-alvo.

Registro e evidência. Registrar escopo, método, população, amostra, evidência, confiança, lacunas, dependências e validação de stakeholders.

Concluído quando. O baseline distingue capacidades ausentes, definidas e operantes e pode ser repetido com o mesmo método.

08.3 Descoberta de ativos e baseline

Decisão/ação obrigatória. Para descoberta de ativos e baseline, a organização deve descobrir ativos implantados, experimentais, embarcados e operados por fornecedores por meio de múltiplas fontes reconciliadas.

Registro e evidência. Reter fonte de descoberta, última visualização, confiança, correspondência de owner, identidade não resolvida e status de remediação.

Concluído quando. Ativos sem owner ou shadow entram em contenção e resolução de ownership em vez de serem silenciosamente aceitos no inventário.

08.4 Avaliação de capacidade e lacunas

Decisão/ação obrigatória. Para avaliação de capacidade e lacunas, a organização deve estabelecer um baseline datado de ativos, capacidades, owners, controles, evidências e dores operacionais antes de desenhar o estado-alvo.

Registro e evidência. Registrar escopo, método, população, amostra, evidência, confiança, lacunas, dependências e validação de stakeholders.

Concluído quando. O baseline distingue capacidades ausentes, definidas e operantes e pode ser repetido com o mesmo método.

08.5 Sistema de governança-alvo

Decisão/ação obrigatória. Para sistema de governança-alvo, a organização deve desenhar as capacidades-alvo de decisão, controle, assurance, registry e operação a partir do baseline e do contexto de risco.

Registro e evidência. Reter capacidades-alvo, authority, interfaces, artefatos exigidos, sequenciamento, aceite e premissas de transição.

Concluído quando. Toda capacidade-alvo fecha uma lacuna ou obrigação documentada e tem owner e critério de saída mensurável.

08.6 Modelo operacional-alvo

Decisão/ação obrigatória. Para modelo operacional-alvo, 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.

08.7 Workstreams priorizados e dependências

Decisão/ação obrigatória. Para workstreams priorizados e dependências, a organização deve sequenciar o trabalho por dependência bloqueante, redução de risco e capacidade utilizável em vez de categoria de documento.

Registro e evidência. Registrar workstream, owner, pré-requisito, marco, entregável, aceite, risco, capacidade e caminho crítico.

Concluído quando. Nenhuma onda promete uma capacidade cuja identidade, dados, authority, evidência ou dependência operacional esteja ausente.

08.8 Financiamento, recursos e competências

Decisão/ação obrigatória. Para financiamento, recursos e competências, a organização deve assegurar sponsor accountable, capacidade financiada e papéis nomeados tanto para a implementação quanto para a operação no business as usual.

Registro e evidência. Registrar orçamento, capacidade, competências, autoridade de decisão, horizonte de financiamento, dependências e riscos não financiados.

Concluído quando. Controles obrigatórios e deveres operacionais têm recursos antes de a coorte ou capacidade relacionada ser aprovada.

08.9 Seleção de tecnologia e procurement

Decisão/ação obrigatória. Para seleção de tecnologia e procurement, a organização deve definir contratos de capacidade e interfaces de extensão independentemente de um produto específico.

Registro e evidência. Registrar comportamento exigido, interface, contrato de dados e identidade, teste de portabilidade, mapping de fornecedor e restrição de saída.

Concluído quando. Um fornecedor pode ser substituído ou isolado sem redefinir a policy, os control IDs, os schemas ou os decision gates.

08.10 Governança mínima viável para a primeira coorte

Decisão/ação obrigatória. Para governança mínima viável para a primeira coorte, a organização deve estabelecer a fundação nomeada antes de expor a primeira coorte representativa.

Registro e evidência. Registrar artefatos mínimos, owners, estados de controle, lacunas bloqueadas, evidência de teste, authority de exceção e backlog de hardening.

Concluído quando. A primeira coorte consegue completar G0–G7 com decisões rastreáveis e nenhuma fundação bloqueante ausente.

08.11 Fundações de policy, papéis e decisão

Decisão/ação obrigatória. Para fundações de policy, papéis e decisão, a organização deve estabelecer a fundação nomeada antes de expor a primeira coorte representativa.

Registro e evidência. Registrar artefatos mínimos, owners, estados de controle, lacunas bloqueadas, evidência de teste, authority de exceção e backlog de hardening.

Concluído quando. A primeira coorte consegue completar G0–G7 com decisões rastreáveis e nenhuma fundação bloqueante ausente.

08.12 Fundações de registry e intake

Decisão/ação obrigatória. Para fundações de registry e intake, a organização deve estabelecer a fundação nomeada antes de expor a primeira coorte representativa.

Registro e evidência. Registrar artefatos mínimos, owners, estados de controle, lacunas bloqueadas, evidência de teste, authority de exceção e backlog de hardening.

Concluído quando. A primeira coorte consegue completar G0–G7 com decisões rastreáveis e nenhuma fundação bloqueante ausente.

08.13 Fundações do processo de risco e impacto

Decisão/ação obrigatória. Para fundações do processo de risco e impacto, a organização deve estabelecer a fundação nomeada antes de expor a primeira coorte representativa.

Registro e evidência. Registrar artefatos mínimos, owners, estados de controle, lacunas bloqueadas, evidência de teste, authority de exceção e backlog de hardening.

Concluído quando. A primeira coorte consegue completar G0–G7 com decisões rastreáveis e nenhuma fundação bloqueante ausente.

08.14 Baseline mínimo de controles e evidências

Decisão/ação obrigatória. Para baseline mínimo de controles e evidências, a organização deve estabelecer a fundação nomeada antes de expor a primeira coorte representativa.

Registro e evidência. Registrar artefatos mínimos, owners, estados de controle, lacunas bloqueadas, evidência de teste, authority de exceção e backlog de hardening.

Concluído quando. A primeira coorte consegue completar G0–G7 com decisões rastreáveis e nenhuma fundação bloqueante ausente.

08.15 Fundações de plataforma e enforcement

Decisão/ação obrigatória. Para fundações de plataforma e enforcement, a organização deve estabelecer a fundação nomeada antes de expor a primeira coorte representativa.

Registro e evidência. Registrar artefatos mínimos, owners, estados de controle, lacunas bloqueadas, evidência de teste, authority de exceção e backlog de hardening.

Concluído quando. A primeira coorte consegue completar G0–G7 com decisões rastreáveis e nenhuma fundação bloqueante ausente.

08.16 Piloto representativo ou coorte de validação

Decisão/ação obrigatória. Para piloto representativo ou coorte de validação, a organização deve selecionar uma coorte que exercite caminhos materiais de risco, dados, identidade, ferramentas, lifecycle e operação sem exposição não controlada.

Registro e evidência. Registrar rationale da seleção, riscos excluídos, critérios de sucesso, salvaguardas, tamanho da coorte, rollback e perguntas de aprendizado.

Concluído quando. A coorte valida o caminho completo de governança e não substitui um demo fácil por evidência representativa.

08.17 Validação de ponta a ponta

Decisão/ação obrigatória. Para validação de ponta a ponta, a organização deve exercitar intake, risco, design, build, avaliação, release, operação, incidente e aposentadoria como um fluxo rastreável.

Registro e evidência. Reter timestamps, handoffs, decisões, artefatos, evidência de sistema, exceções, defeitos e remediação.

Concluído quando. Todos os gates e owners trabalham no mesmo caso e defeitos de integração não resolvidos bloqueiam o rollout amplo.

08.18 Release controlado e aprendizado

Decisão/ação obrigatória. Para release controlado e aprendizado, a organização deve liberar por coortes ou estágios delimitados com critérios explícitos de promoção, pausa e rollback.

Registro e evidência. Registrar coorte, exposição, telemetria, thresholds, aprovação, resultado observado, incidentes e decisão do próximo estágio.

Concluído quando. A expansão ocorre somente após o estágio anterior atingir os critérios e um sinal adverso pode interromper ou reverter o rollout.

08.19 Tratamento de agentes existentes e shadow

Decisão/ação obrigatória. Para tratamento de agentes existentes e shadow, a organização deve triar ativos existentes em caminhos de registrar, restringir, remediar, migrar, suspender ou aposentar usando um plano datado.

Registro e evidência. Registrar confiança da descoberta, owner, exposição atual, controle provisório, estado-alvo, prazo e authority.

Concluído quando. Status legado não é isenção permanente e ativos de alto risco vencidos são contidos.

08.20 Ondas de rollout

Decisão/ação obrigatória. Para ondas de rollout, a organização deve liberar por coortes ou estágios delimitados com critérios explícitos de promoção, pausa e rollback.

Registro e evidência. Registrar coorte, exposição, telemetria, thresholds, aprovação, resultado observado, incidentes e decisão do próximo estágio.

Concluído quando. A expansão ocorre somente após o estágio anterior atingir os critérios e um sinal adverso pode interromper ou reverter o rollout.

08.21 Paved road e self-service

Decisão/ação obrigatória. Para paved road e self-service, a organização deve fornecer defaults conformes reutilizáveis, automação e orientação para padrões comuns preservando escalonamento para exceções.

Registro e evidência. Registrar padrões suportados, controles embutidos, contrato do usuário, versão, telemetria, modelo de suporte e condições de escape.

Concluído quando. Um time consegue completar o caminho padrão com menos esforço manual e não pode usar self-service para contornar revisão bloqueante.

08.22 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.

08.23 Comunicação e gestão de mudança

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

08.24 Champions e canais de feedback

Decisão/ação obrigatória. Para champions e canais de feedback, 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.

08.25 Prontidão de suporte e operação

Decisão/ação obrigatória. Para prontidão de suporte e operação, a organização deve comprovar que owners permanentes, níveis de suporte, runbooks, acesso, monitoramento, capacidade e backlog estão prontos antes do handoff.

Registro e evidência. Reter aceite de serviço, assinatura do owner, modelo de suporte, SLO, teste de runbook, dívida conhecida, treinamento e escalonamento.

Concluído quando. Times do business as usual resolvem um problema representativo e aceitam o trabalho residual sem dependência do projeto de implementação.

08.26 Transferência para ownership permanente

Decisão/ação obrigatória. Para transferência para ownership permanente, a organização deve comprovar que owners permanentes, níveis de suporte, runbooks, acesso, monitoramento, capacidade e backlog estão prontos antes do handoff.

Registro e evidência. Reter aceite de serviço, assinatura do owner, modelo de suporte, SLO, teste de runbook, dívida conhecida, treinamento e escalonamento.

Concluído quando. Times do business as usual resolvem um problema representativo e aceitam o trabalho residual sem dependência do projeto de implementação.

08.27 Critérios de saída para operação em regime permanente

Decisão/ação obrigatória. Para critérios de saída para operação em regime permanente, a organização deve comprovar que owners permanentes, níveis de suporte, runbooks, acesso, monitoramento, capacidade e backlog estão prontos antes do handoff.

Registro e evidência. Reter aceite de serviço, assinatura do owner, modelo de suporte, SLO, teste de runbook, dívida conhecida, treinamento e escalonamento.

Concluído quando. Times do business as usual resolvem um problema representativo e aceitam o trabalho residual sem dependência do projeto de implementação.

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/adoption/README.md

Commit de origem: 5545d9227624400ab8bb707b6032b2f61329a36e.

Título controlado na origem: Adoção, enablement e suporte

Adoção, enablement e suporte

Objetivo

Preparar builders, usuários, líderes e suporte para criar, descobrir, usar e operar capacidades de IA com segurança e efetividade.

Adoção não é comunicação de lançamento. É a capacidade organizacional de usar o sistema de forma correta, obter suporte, reportar falhas e incorporar feedback ao governance lifecycle.

Personas

Persona	Necessidade
sponsor	value, risco, decisões e accountability
business owner	outcome, usuários, limites e attestation
maker/engineer	paved road, controls, templates e feedback rápido
end user	intended use, limitações, suporte e contestação
administrator	policy, inventory, access e remediation
support	triage, known issues, escalation e communication
domain authority	evidências relevantes e decision rights
auditor	acesso independente a records e rationale

Discovery e catalog

Um catálogo útil permite:

• encontrar capacidades aprovadas por tarefa e persona;
• distinguir status, owner, versão e tier;
• entender intended/prohibited use;
• acessar support e feedback;
• evitar duplicação;
• ocultar ou bloquear itens em quarantine/sunset;
• medir discovery separado de criação.

Publicar sem discovery gera agentes invisíveis; discovery sem lifecycle promove itens inadequados.

Paved road para builders

• starter templates com identity, logging e policy hooks;
• schemas e self-assessment proporcionais;
• approved models, data connectors e tools;
• automated checks com feedback acionável;
• sandbox e test datasets;
• design clinic e office hours;
• exception process com owner e expiry;
• documentação de examples e failure modes.

O paved road deve ser mais simples que contornar a governança.

A sequência que o builder percorre nesse caminho — do registro do caso de uso à retirada — está em developer experience e paved road, com os building blocks e as métricas de fricção correspondentes.

Suporte em camadas

1. Self-service: documentação, status, FAQ e runbooks.
2. AI-assisted: busca e triage com handoff rastreável.
3. Platform/IT backstop: incidentes, acesso e operação.
4. Domain SME: security, privacy, RAI, legal, data ou negócio.
5. Authority escalation: containment, risk acceptance e policy decision.

Change e comunicação

Mudanças materiais comunicam:

• o que mudou e por quê;
• quem é afetado;
• novos limites ou ações;
• data de vigência;
• treinamento ou suporte necessário;
• rollback/contingency;
• canal de feedback e owner.

Feedback loop

flowchart LR
    U[Uso] --> F[Feedback/sinal]
    F --> T[Triage]
    T --> B[Backlog]
    B --> D[Decisão]
    D --> C[Change]
    C --> E[Evaluate]
    E --> U

Feedback é evidência contextual, não prova isolada de valor ou segurança.

Playbook de implantação

Governança só escala quando cada papel consegue executá-la sem depender do time central para cada decisão. Adoção transforma regra em competência prática, suporte e hábito.

1. Segmentar personas. Citizen builder, desenvolvedor profissional, business owner, technical owner, reviewer, administrador de plataforma, operação de segurança, data owner, sponsor e usuário final. Cada persona tem objetivo de aprendizagem distinto.
2. Separar awareness de competência. Awareness ensina a reconhecer a regra e pedir ajuda; competência exige executar a atividade e demonstrar resultado. Não habilite um reviewer de impact assessment porque ele concluiu um treinamento introdutório.
3. Montar currículo por papel e risco. Builders precisam de registry, risco, dados, ferramentas, identidade e telemetria; owners precisam de accountability, valor e attestation; reviewers precisam de critérios e evidência; segurança precisa de contenção e forensics. Com laboratórios e casos calibrados.
4. Implantar rede de champions. Escolher áreas por volume e risco, definir tempo alocado e limite de autoridade. O champion orienta a primeira linha e escala; não substitui as funções de controle nem aprova localmente o que exige authority.
5. Tornar o caminho governado o mais fácil. Builders aprovados, templates, catálogos de fontes e ferramentas, office hours, policy gates self-service e exemplos. Fricção desnecessária é o principal produtor de shadow AI.
6. Calibrar reviewers com casos comuns. Os mesmos 10 a 20 casos aplicados por reviewers diferentes. Divergência vira discussão de critério, não preferência individual. Versionar os exemplos quando o standard mudar.
7. Criar suporte e comunidade de prática. Office hours, FAQ, canais de escalation e encontros regulares reduzem retrabalho. Perguntas recorrentes viram melhoria de documentação e automação.
8. Medir eficácia, não conclusão. Taxa de conclusão de treinamento é métrica fraca isolada. Medir verificação de conhecimento, retrabalho de review, violações de policy, tickets de suporte, tempo até assessment, qualidade da evidência e padrões de shadow AI — e ajustar o currículo com esses sinais.

Evidências

• persona e stakeholder map;
• adoption/support plan;
• catalog entry e discovery analytics;
• learning assets;
• support model e escalation;
• training/competence records;
• feedback backlog e decisões;
• change communication;
• user research e accessibility findings.

Métricas

• discovery-to-use conversion;
• active/recurring users por persona;
• duplicate creation;
• support demand e resolution time;
• training completion e task competence;
• misuse/incorrect-use reports;
• feedback-to-decision time;
• adoption com qualidade e outcome, não apenas login.

Failure modes

• medir sucesso por agentes criados;
• publicar sem owner ou suporte;
• treinamento único para todos;
• champion network sem authority ou tempo;
• usar feedback positivo como prova de ROI;
• esconder limitation para aumentar adoção;
• ignorar resistência como “falta de cultura”;
• manter itens em discovery durante quarantine.

Decision gate

Release para audiência ampla exige catalog entry, intended use, limitations, support owner, escalation, communication e feedback channel.

Fonte: docs/devex/README.md

Commit de origem: 5545d9227624400ab8bb707b6032b2f61329a36e.

Developer experience e paved road

Governança deve aparecer no fluxo de entrega, não apenas em documentos. O paved road reduz decisões repetitivas e preserva escalation para exceções.

Golden path

1. registrar use case, owner e prohibited use;
2. criar registry record e blueprint;
3. classificar risk tier e red flags;
4. selecionar approved model, data e tool contracts;
5. aplicar controls e evaluation strategy;
6. produzir release evidence;
7. obter decisão no gate aplicável;
8. publicar com observability, containment e rollback;
9. operar, regress, attest e sunset.

Building blocks

• templates e examples versionados;
• CI para schemas, controls e links;
• identity e data patterns aprovados;
• tool/MCP gateway;
• evaluation harness e negative scenarios;
• runtime event e evidence standards;
• self-service com escalation claro.

Métricas

• lead time por gate e tier;
• rework causado por requirement tardio;
• coverage do paved road;
• exception rate e expiry;
• evidence freshness;
• containment/recovery readiness.

Automation não deve esconder decision rights ou transformar falha de validação em aprovação implícita.

Fonte: docs/governance/ai-agent-policy-and-governance-v1.md

Commit de origem: 5545d9227624400ab8bb707b6032b2f61329a36e.

17. Suggested Action Plan

0–30 days: Do’s & Don’ts + Self-Assessment + Approval Matrix + HITL Policy + Minimum Catalog; initial alignment with stakeholders. 30–60 days: Complete agent policy; audit and observability playbook; pilots in 1–2 segments; review by the Digital Council (1 week). 60–90 days: Corporate publication; training; progressive adoption (require Self-Assessment for new agents and migration of legacy ones to the catalog).

Fonte: docs/guides/capability-map.md

Commit de origem: 5545d9227624400ab8bb707b6032b2f61329a36e.

Título controlado na origem: Capability map — atual versus alvo

Capability map — atual versus alvo

Objetivo

Separar o que a organização precisa saber fazer de qual ferramenta vai implementar. O capability map existe para evitar o erro mais caro de um programa de governança: comprar tecnologia para um problema que é, na verdade, ausência de processo, ownership, dados ou decision rights.

O que é uma capability

Uma capacidade organizacional de produzir um resultado de forma repetível. Não é uma ferramenta, um time nem um projeto.

"Agent registry" é uma capability quando a empresa consegue descobrir, registrar, manter e consultar agentes com qualidade conhecida. Uma plataforma pode implementar parte dela — não é ela.

O teste: se você trocar o produto e a capacidade desaparecer, você comprou uma ferramenta e chamou de capability.

As capacidades do framework

Ponto de partida: os domínios canônicos. Quebre uma capability em duas apenas quando a filha tiver owner, processo ou evidência diferentes.

Capacidade	Pergunta de diagnóstico	Sinal típico de estado inicial	Alvo comum
estratégia e governança	existe mandato, portfólio, funding e decisão clara?	política genérica de IA, sem charter ou priorização de agentes	charter aprovado, fóruns, decision rights, risk appetite e portfolio review
estate inventory e registry	sabemos quais agentes existem, onde operam e quem responde?	planilhas por plataforma e baixa cobertura de shadow agents	discovery contínuo + registry corporativo reconciliável
risco e Responsible AI	risco, admissibilidade e impacto roteiam controles?	mesma review para todos os casos	tiers, admissibilidade, escaladores e impact assessment por gatilho
lifecycle e Agent SDLC	versões, estados e mudanças estão governados?	publicação ad hoc e approvals permanentes	stage/state, gates, transition history, attestation e retirada
identidade e acesso	cada ação é atribuível e autorizada?	chaves e contas de serviço compartilhadas	identidade própria por agente, least privilege, JML e delegação quando aplicável
dados e conhecimento	as fontes são classificadas, permitidas e AI-ready?	recuperação sobre qualquer pasta autorizada	catálogo de fontes certificadas com lineage, restrictions e recertification
tools, APIs e MCP	as ações são catalogadas, limitadas e mediadas?	ferramentas embutidas por time	enterprise tool registry, gateway e autorização por ação/parâmetro
modelos e provedores	combinações e versões possuem critérios de admissão e saída?	escolha por preferência do time	catálogo provider/model/version, evaluation binding, fallback e exit strategy
runtime e plataforma	existem enforcement, isolamento, resiliência e rollback?	acesso direto a endpoints e configuração por agente	control plane, policy enforcement, budgets, containment e recovery patterns
segurança e AgentSecOps	ameaças agentic entram em prevention, detection e response?	SOC vê apenas logs tradicionais	threat model agentic, red teaming, supply-chain controls e incident integration
observabilidade e behavioral analytics	é possível reconstruir, detectar desvio e agir?	logs de aplicação sem correlation ou owner action	event envelope, traces, baselines, thresholds, runbooks e feedback loop
FinOps	custo é atribuível a agente, tarefa e outcome?	custo por chave ou centro de custo agregado	budgets, unit economics, anomaly response e arquitetura guiada por custo/qualidade
value realization	outcomes influenciam funding, expansão e sunset?	contagem de agentes e relatos de benefício	baseline, KPI, attribution caveats e portfolio decisions por evidência
assurance e auditabilidade	controls e decisões podem ser testados por challenge apropriado?	evidence preparada manualmente para auditoria	continuous evidence, segregation, sampling, findings e assurance proporcional
adoção, suporte e competências	cada papel consegue usar a rota governada corretamente?	treinamento pontual e suporte informal	currículo por papel, champions, support model e feedback incorporado aos standards

Procedimento

1. Listar as capacidades necessárias ao operating model.
2. Escrever uma frase de outcome para cada uma. Exemplo: "toda ação material de agente é atribuível a uma identidade conhecida e autorizada".
3. Definir evidências observáveis do estado atual. Evite "o controle de acesso é forte". Prefira: "74% dos T2/T3 usam identidade dedicada; 26% usam chave compartilhada".
4. Atribuir maturidade com base em evidência e registrar confidence. Evidência fraca produz nota provisória, não nota otimista.
5. Definir o alvo por horizonte e necessidade de negócio. Nem toda capacidade precisa do nível máximo; nível 3 costuma bastar no primeiro ano.
6. Identificar dependências. Behavioral analytics confiável depende de identidade própria e telemetria consistente — priorizá-la antes disso desperdiça o investimento.
7. Converter gaps materiais em iniciativas do roadmap de maturidade.

Exemplo

Capability	Estado atual observado	Alvo 12m	Gap concreto	Iniciativa
identidade	chaves compartilhadas; owner não rastreável em 30% dos agentes transacionais	100% de T2/T3 com identidade própria, JML e rotação	atribuição, lifecycle e least privilege insuficientes	padrão de identidade + onboarding + automação de JML
tools e MCP	ferramentas embutidas por time, sem catálogo nem classificação de ação	ferramentas críticas registradas, classificadas e mediadas	sem visão da capacidade executável nem do risco por ação	tool registry + broker + autorização por parâmetro
observabilidade	logs de aplicação; custo por chave; sem correlação agente-tarefa-ferramenta	schema de telemetria e dashboards por decisão	impossível investigar um agente ou medir custo por resultado	schema + correlation IDs + pipeline

Repare no primeiro: o gap não é "comprar IAM". É identidade não humana por agente, least privilege, lifecycle de owner, gestão de secrets e auditabilidade. Nenhum produto entrega isso sozinho.

Perguntas de challenge

Aplique antes de aprovar o alvo:

• o alvo é necessário para o risco e o volume previstos, ou está sendo escolhido por ambição tecnológica?
• existe dependência invisível em outra capacidade que pode bloquear a iniciativa?
• o alvo pode ser demonstrado por evidência objetiva?
• existe owner capaz de sustentar a capacidade depois que o programa terminar?

A última derruba mais iniciativas que as outras três somadas.

Failure modes

• mapear produtos e chamar de capacidades;
• quebrar capacidades até virarem tarefas, perdendo o nível de decisão;
• alvo máximo em tudo, ignorando dependência e capacidade operacional;
• estado atual descrito por adjetivo em vez de medida;
• ignorar que uma capacidade em nível baixo pode inutilizar outra em nível alto;
• aprovar alvo sem owner que o sustente depois do programa.

Fonte: docs/guides/framework-implementation-playbook.md

Commit de origem: 5545d9227624400ab8bb707b6032b2f61329a36e.

Título controlado na origem: Implementation playbook do framework de governança

Implementation playbook do framework de governança

Objetivo

Implantar um sistema de governança proporcional, federado e verificável. O playbook organiza outcomes, atividades, artefatos e decision gates; não prescreve produto, organograma ou prazo universal.

Como usar

1. Defina o mandato e o escopo organizacional.
2. Faça baseline com evidência, sem preencher lacunas por suposição.
3. Selecione os controls mínimos por risco e capacidade.
4. Implemente governance como fluxo, não como documento isolado.
5. Teste handoffs, enforcement, contenção e evidência.
6. Meça operação e valor separadamente.
7. Revise decisões quando contexto, risco ou evidência mudarem.

Workstreams

• estratégia, portfólio e valor;
• operating model e accountability;
• registry, blueprint e lifecycle;
• identidade e dados;
• tools, APIs e MCP;
• risco, Responsible AI e assurance;
• evaluations e release;
• adoção, suporte e change;
• runtime, auditabilidade e resposta.

Contrato comum dos decision gates

Os gates são decisões registradas, não nomes de fase. Workstreams podem avançar em paralelo, mas nenhum gate é concluído apenas porque o prazo terminou ou um documento foi produzido.

Estados de decisão

Estado	Significado	Requisito de registro
approve	critérios de saída atendidos para o escopo e versão avaliados	authority, data, versão e evidências aceitas
condition	avanço permitido com gap não crítico e compensação temporária	condição, owner, prazo, compensating control e expiry
hold	decisão suspensa por evidência insuficiente ou remediação necessária	finding, owner, ação, evidência esperada e nova data
reject	risco, desenho ou escopo não é aceitável no appetite vigente	rationale, authority, opções de redesign ou encerramento

Todo decision record deve identificar gate_id, escopo, versão, tier, authority, participantes, evidence refs, estado, rationale, condições, expiry e próxima revisão. Missing evidence nunca equivale a aprovação. A mesma pessoa não pode construir, aprovar e desafiar o próprio artefato quando segregation of duties for exigida pelo tier ou por obrigação aplicável.

Contratos por gate

Gate	Critérios de entrada	Evidência mínima	Authority da decisão	Critérios de saída	Falha e remediação
G0 — Mandato	sponsor candidato, problema e boundary inicial	draft de charter, scope, authorities e obligations map	sponsor executivo, com governance owner	mandato, scope, appetite, containment authority e regra de exceção aprovados	hold para esclarecer escopo/authority; não automatizar approvals
G1 — Baseline	G0 aprovado e acesso às fontes e stakeholders	inventários com coverage, current-state map, gaps, limitações e confidence	governance owner, com domain owners; sponsor aceita limitações materiais	baseline separa observado de hipótese e todo gap crítico tem owner	hold; unknowns de alto impacto são restringidos ou isolados até avaliação
G2 — Fundações	G1 aceito e população in-scope identificada	registry, blueprints, ownership, identity/data/tool records e testes de revogação	Design Authority e authorities de identity, data e tools	records mínimos validam, owners aceitam responsabilidade e acessos são revogáveis	bloquear onboarding, restringir connector/tool ou retornar para correção
G3 — Operating model	G0 vigente, handoffs atuais conhecidos e G2 suficiente para atribuir responsabilidade	operating model, RACI, decision matrix, exception flow, SLAs e charters	sponsor/Governance Council, com aceite das domain authorities	cada decisão material possui accountable, receiver, prazo e escalation	hold; decisões não delegadas retornam à authority existente
G4 — Controls e assurance	tiering proposto, G2/G3 aceitos e obligations map disponível	risk rationale, baseline por tier, assessments, evaluation plan, evidence index e residual-risk record	Design Authority e domain authorities; residual risk pela authority designada	controles bloqueantes possuem design, owner, teste e evidence requirement	hold ou reject; remediar, reduzir capability/escopo ou elevar authority
G5 — Onboarding/release	G4 aprovado para o escopo e versão, suporte e operação preparados	blueprint versionado, checks, evidence package, conditions, run readiness e release record	release/Design Authority definida no operating model	release approve/condition registrado e catalog entry publicável	não liberar; corrigir, reclassificar, restringir ou rejeitar
G6 — Operação	G5 válido e sistema instrumentado antes de exposição material	telemetry map, thresholds, runbooks, on-call, drills, rollback/quarantine e incident evidence	Run Authority, com domain escalation	sinais possuem owner/action e containment, recovery e reactivation foram exercitados	conter, fazer rollback ou suspender; reativação exige cause e regression evidence
G7 — Valor e lifecycle	janela de operação definida, G6 aceito e baseline de outcome/custo disponível	owner attestation, use/quality/risk/value evidence, incidents, costs e sunset options	Business Owner; Governance Council para decisão de portfólio/material risk	decisão de manter, expandir, corrigir, restringir ou aposentar registrada	restringir/sunset ou abrir remediation; mudança normativa segue processo separado

A numeração não é um cronograma

G0–G7 são pontos de decisão com dependência declarada, não etapas em ordem cronológica. A numeração ajuda a referenciar; ela não diz em que semana cada gate acontece.

A dependência real está na coluna de critérios de entrada acima:

Gate	Depende de
G0	—
G1	G0
G2	G1
G3	G0 vigente e G2 suficiente para atribuir responsabilidade — não G2 completo
G4	G2 e G3
G5	G4, para aquele escopo e versão
G6	G5
G7	G6

A consequência prática é que G2 e G3 se sobrepõem. Basta ter registry e ownership o bastante para saber a quem atribuir uma decisão; o resto das fundações continua sendo construído enquanto o operating model é aprovado. Por isso o programa de 24 semanas fecha G3 na fase F2 e completa G2 na F3 — não é inversão, é paralelismo legítimo.

Um cronograma montado assumindo que a ordem numérica é a ordem de execução vai travar em F2 esperando um G2 completo que o G3 não exige.

Gate 0 — Mandato, escopo e sponsorship

Outcome

Existe autoridade para definir requisitos, exigir evidências e conter sistemas fora do envelope aprovado.

Atividades

• nomear sponsor e governance owner;
• definir sistemas, unidades, regiões e ambientes cobertos;
• declarar risk appetite e red flags;
• mapear obrigações e authorities existentes;
• definir o que permanece fora de escopo e por quanto tempo;
• estabelecer princípios e regra de versionamento.

Entregáveis

• governance charter;
• scope map;
• stakeholder/authority map;
• initial risk appetite;
• decision log;
• communication plan.

Gate questions

• quem pode aprovar, condicionar, conter e aposentar?
• o escopo inclui SaaS, low-code, shadow AI e agentes adquiridos?
• exceções têm authority e expiry?

Sem mandato, não automatize approvals nem prometa cobertura.

Gate 1 — Diagnóstico e baseline

Outcome

A organização conhece sua situação atual, lacunas e limitações de evidência.

Atividades

• aplicar maturity assessment;
• reconciliar inventários e sources;
• entrevistar owners e domain authorities;
• mapear lifecycle real, approvals e handoffs;
• revisar incidentes, findings, exceções e métricas;
• identificar duplicidade, ownerless assets e high-risk unknowns.

Entregáveis

• maturity baseline;
• current-state map;
• preliminary inventory;
• gap/risk register;
• evidence quality statement;
• prioritized decisions.

Gate questions

• quais conclusões são observadas e quais são hipóteses?
• quais lacunas críticas não possuem owner?
• onde a organização possui policy sem enforcement ou evidence?

Gate 2 — Fundações de dados, identidade e ownership

Outcome

Cada agente possui identidade, owner, finalidade, dados e capabilities rastreáveis.

Atividades

• aprovar schemas de registry e blueprint;
• escolher source of truth e reconciliation strategy;
• registrar business/technical owner;
• definir workload identity e permission mapping;
• criar data contracts e connector gates;
• inventariar tools, APIs e MCP servers;
• definir material changes e lifecycle states.

Entregáveis

• registry operacional;
• agent blueprints;
• identity records;
• data contracts;
• tool/MCP registry;
• ownership e attestation rules.

Gate questions

• é possível responder o que existe e quem responde?
• blueprint explica arquitetura e blast radius?
• identidades, connectors e tools podem ser revogados?

Gate 3 — Operating model e decision rights

Outcome

Decisões têm authority, handoffs, SLA e evidência definidos.

Atividades

• instituir Governance Council, Design Authority e Run Authority adequados ao contexto;
• definir domain authorities;
• criar RACI e decision matrix;
• separar build, approval, run e challenge conforme tier; usar independent assurance somente quando segregation e conflict rules estiverem formalizadas;
• desenhar exception e waiver process;
• definir forums e cadences.

Entregáveis

• target operating model;
• RACI/decision rights;
• forum charter;
• handoff map;
• exception process;
• service levels.

Gate questions

• accountability está atribuída a funções reais, não a “o time”?
• Run Authority pode conter sem depender de council?
• exceção sem expiry é bloqueada?

Gate 4 — Controls mínimos e assurance

Outcome

Risco é classificado e traduzido em controls, assessments, tests e residual-risk decisions.

Atividades

• aprovar tiers e red flags;
• mapear control catalog à policy e aos domínios;
• definir triggers de impact, privacy, security e release assessments;
• criar evaluation strategy e evidence package;
• definir human oversight e transparency;
• testar negative paths, rollback e kill switch;
• estabelecer risk acceptance authority.

Entregáveis

• risk matrix;
• control baseline por tier;
• assessment suite;
• evaluation/release criteria;
• human oversight design;
• evidence package index.

Gate questions

• cada control tem owner e evidence?
• ausência de evidência aparece como missing, não como passed?
• approval é proporcional e possui caminho de remediation?

Gate 5 — Onboarding por tier de risco

Outcome

Existe um paved road para registrar, avaliar, liberar e suportar agentes em cada tier.

Atividades

• integrar registry, blueprint, controls e release flow;
• criar starter templates e approved components;
• configurar automated checks onde policy está estável;
• publicar guidance, examples e support channels;
• validar experience de maker, reviewer, owner e operator;
• impedir bypass de paths críticos.

Entregáveis

• onboarding workflow;
• release checklist;
• approved component catalog;
• builder guidance;
• support/escalation model;
• audit trail do gate.

Gate questions

• o paved road é mais simples que contornar a governança?
• o workflow diferencia risco e capability?
• condições e findings chegam ao owner correto?

Gate 6 — Operação, observabilidade e resposta

Outcome

Sinais geram decisões e ações de contenção, remediação e recuperação.

Atividades

• instrumentar agent, identity, data e tool chain;
• definir SLOs, thresholds e alerts;
• implementar quarantine, rollback e reactivation;
• executar incident e containment drills;
• ligar support, SOC/SRE e domain escalation;
• preservar evidence e update regression suite.

Entregáveis

• observability model;
• dashboards com owner/threshold/action;
• incident severity e runbooks;
• quarantine/rollback evidence;
• runtime control mapping;
• post-incident loop.

Gate questions

• o dashboard muda uma decisão?
• containment funciona sem cooperação do agente?
• reactivation exige cause e regression evidence?

Gate 7 — Valor, attestation e melhoria contínua

Outcome

O portfólio é revisado por ownership, risco, qualidade, uso, outcome e custo.

Atividades

• separar criação, discovery, adoção, uso, qualidade e valor;
• revisar business case e baseline;
• executar attestation conforme tier;
• analisar concentração, duplicidade e agents inativos;
• decidir manter, expandir, corrigir, restringir ou aposentar;
• atualizar policy, controls e patterns somente por processo versionado.

Entregáveis

• value review;
• attestation record;
• portfolio decisions;
• improvement backlog;
• sunset records;
• change proposal versionada.

Gate questions

• há outcome observável ou apenas uso?
• custo inclui operação, suporte e assurance?
• policy changes estão separadas de guidance?

Sequenciamento

Os gates possuem dependências lógicas, mas workstreams podem avançar em paralelo. Não espere perfeição para começar; também não use urgência para pular ownership, identidade, risco ou containment.

Definition of done

A implantação está operacional quando:

• o inventário é reconciliável e possui owners;
• tier determina controls e authority;
• release evidence é recuperável;
• identities, data e tools são revogáveis;
• runtime signals acionam runbooks;
• quarantine, rollback e sunset foram exercitados;
• attestation e value review mudam o portfólio;
• exceptions vencem;
• policy e guidance são versionados separadamente.

O que este playbook não faz

• não substitui análise jurídica ou regulatória;
• não define threshold universal;
• não seleciona produto;
• não comprova maturidade por documentação;
• não certifica conformidade;
• não promete resultado financeiro.

Fonte: docs/guides/implementation-plan-90-days.md

Commit de origem: 5545d9227624400ab8bb707b6032b2f61329a36e.

Título controlado na origem: Roadmap de implantação — 90 dias

Roadmap de implantação — 90 dias

Referência acelerada, não SLA. Os 90 dias ajudam equipes que precisam de uma sequência inicial. Adapte duração e sobreposição às dependências, ao estate e à capacidade da organização. O calendário nunca substitui G0–G7 nem cria obrigação de piloto.

Objetivo

Estabelecer, em 90 dias, as fundações e os fluxos mínimos de um sistema de governança operável: mandato, baseline, registry, blueprint, tiers, decision rights, controls, release evidence, runtime response e roadmap priorizado.

O resultado não é “governança concluída”. É uma capacidade inicial verificável que pode ser ampliada sem perder accountability ou rastreabilidade.

Constraints

• A policy modular é a fonte canônica; adoção organizacional requer release e authority explícitas.
• Core e controls são multiplataforma.
• Thresholds são aprovados no contexto da organização.
• Dados, identidade, segurança, privacy, legal e RAI mantêm suas authorities.
• Automação é aplicada somente a regras estáveis e testadas.
• Lacuna de evidência permanece visível; não é preenchida por suposição.
• Este roadmap não exige piloto: uma coorte de onboarding ou rollout controlado delimita o primeiro escopo operacional e usa os mesmos gates, controls e critérios de produção.

Mapeamento entre calendário e gates

Os períodos abaixo organizam trabalho; os gates continuam sendo decisões independentes. Chegar ao último dia de uma fase não autoriza avanço automático.

Período	Gates preparados ou decididos	Decisão esperada
dias 0–10	G0	aprovar, condicionar, suspender ou rejeitar mandato e scope
dias 11–25	G1	aceitar baseline e limitações ou exigir evidência/remediação
dias 26–40	G2	aceitar fundações mínimas ou bloquear onboarding
dias 41–55	G3 e preparação de G4	aprovar decision rights e autorizar desenho da baseline de controls
dias 56–70	G4 e preparação de G5	aceitar baseline/assurance e decidir readiness para release
dias 71–85	G5 e G6	decidir release condicionado ao tier e aceitar operação/containment
dias 86–90	G7	decidir continuidade, restrição, expansão, remediação ou sunset

O contrato comum dos gates define evidence mínima, authority, estados e caminho de falha. Uma decisão hold ou reject altera o plano; o calendário deve ser replanejado, não usado para contornar o gate.

Dias 0–10 — Mandato e escopo

Atividades

• nomear sponsor, governance owner e authorities iniciais;
• aprovar escopo organizacional e ambientes;
• definir risk appetite, red flags e autoridade de containment;
• mapear policies, processos, inventários e ferramentas existentes;
• selecionar um portfólio inicial representativo para onboarding controlado;
• registrar decisões e dependências.

Entregáveis

• governance charter;
• scope e stakeholder map;
• authority matrix inicial;
• risk appetite v0.1;
• decision/risk log.

Exit criteria

• sponsor e owners nominativos;
• scope explícito;
• containment authority definida;
• nenhuma lacuna crítica sem owner.

Dias 11–25 — Diagnóstico e baseline

Atividades

• aplicar maturity assessment;
• reconciliar inventários de plataformas;
• mapear lifecycle e handoffs reais;
• identificar ownerless, duplicados, inativos e high-risk unknowns;
• avaliar qualidade da evidência;
• priorizar gaps por impacto, dependência e reversibilidade.

Entregáveis

• maturity baseline;
• current-state map;
• preliminary registry;
• gap/risk register;
• prioritized backlog.

Exit criteria

• situação atual separa observado de hipótese;
• inventário possui coverage declarado;
• gaps críticos e altos têm owner e prazo;

Dias 26–40 — Registry, blueprint, dados e identidade

Atividades

• aprovar schemas mínimos;
• definir source of truth e reconciliation;
• registrar business/technical owners e lifecycle;
• preencher blueprints do portfólio inicial;
• mapear workload identities e permissions;
• criar data contracts e connector gates;
• inventariar tools, APIs e MCP servers.

Entregáveis

• registry e blueprints versionados;
• identity/permission matrix;
• data contracts;
• tool/MCP registry;
• material-change triggers.

Exit criteria

• todos os itens do escopo inicial têm owner e status;
• identities, data e tools são rastreáveis;
• gaps aparecem como missing evidence.

Dias 41–55 — Operating model e controls

Atividades

• formalizar Council, Design Authority e Run Authority;
• definir RACI e decision rights por tier;
• aprovar risk tiers e red flags;
• mapear control catalog e evidence;
• definir exception/waiver e expiry;
• estabelecer forums, handoffs e SLAs.

Entregáveis

• target operating model;
• RACI e decision matrix;
• risk/control baseline;
• exception process;
• forum charter.

Exit criteria

• cada decisão material possui accountable;
• segregation of duties é proporcional;
• exceções não podem ser permanentes por padrão.

Dias 56–70 — Assurance, evaluations e release

Atividades

• definir triggers de assessments;
• criar evaluation strategy e thresholds;
• documentar human oversight e transparency;
• montar release evidence package;
• testar negative paths, rollback, quarantine e kill switch;
• registrar residual risk e conditions.

Entregáveis

• assessment suite;
• evaluation/release criteria;
• evidence package;
• run readiness checklist;
• drill records.

Exit criteria

• controls aplicáveis possuem evidence;
• release authority consegue aprovar, condicionar ou negar;
• containment e rollback foram exercitados.

Dias 71–85 — Onboarding, operação e suporte

Atividades

• colocar o workflow de onboarding em uso no escopo inicial;
• configurar telemetry, dashboards e alerts;
• publicar catalog entries, guidance e support paths;
• ligar incident, support e domain escalation;
• medir fricção, gaps e bypass attempts;
• corrigir controls e templates pelo processo versionado da policy modular.

Entregáveis

• onboarding workflow operacional;
• observability e runbooks;
• catalog/discovery;
• support model;
• remediation backlog.

Exit criteria

• cada signal possui owner e action;
• ações state-changing têm correlation;
• support e escalation funcionam ponta a ponta.

Dias 86–90 — Attestation e roadmap

Atividades

• executar primeira owner attestation do escopo;
• revisar criação, discovery, uso, qualidade e value hypothesis separadamente;
• registrar decisões de manter, corrigir, restringir ou aposentar;
• atualizar maturity baseline com evidência;
• aprovar roadmap de expansão e automation backlog.

Entregáveis

• attestation records;
• portfolio/value review;
• maturity delta com limitações;
• roadmap 6–12 meses;
• executive decision memo.

Exit criteria

• decisões ligadas a evidência;
• próximos increments possuem owner, dependency e acceptance criteria;
• nenhuma mudança normativa é autoaprovada.

Métricas dos 90 dias

Cobertura e controle

• coverage do registry;
• owners e attestations válidos;
• identities/connectors/tools classificados;
• evidence packages completos por tier;
• exceptions e findings vencidos;
• containment e rollback drill pass rate.

Fluxo

• cycle time por gate e tier;
• devoluções por evidência incompleta;
• time to decide/contain/remediate;
• bypass attempts e causes;
• suporte e escalation resolution time.

Uso, qualidade e valor

• discovery, adoption e use separados;
• task success e erro por scenario;
• safety/security signals;
• support burden;
• baseline e outcome evidence disponível;
• custo de operação e assurance.

Riscos de execução

Risco	Mitigação
burocracia uniforme	tiering, paved road e forms proporcionais
catálogo decorativo	reconciliation, owners, lifecycle e actions
falso senso de coverage	declarar sources, missing evidence e confidence
centralização em silo	authorities distribuídas e handoffs
automação prematura	manual first para regras instáveis; automate after evidence
métricas de vaidade	separar criação, uso, qualidade e outcome
vendor lock-in	capabilities e schemas neutros; adapters separados
rollout sem containment	quarantine/rollback como exit criteria

Próximo passo após 90 dias

Expandir coverage, automatizar controles estáveis, aprofundar domains com maior residual risk e revisar o roadmap. Uma futura Policy v2, se necessária, deve seguir processo formal de mudança e não é consequência automática deste roadmap.

Fonte: docs/guides/implementation-program-24-weeks.md

Commit de origem: 5545d9227624400ab8bb707b6032b2f61329a36e.

Título controlado na origem: Programa de implantação em 24 semanas

Programa de implantação em 24 semanas

Pattern de referência, não calendário normativo. As 24 semanas oferecem um ponto de partida para equipes que ainda não sabem como organizar a implantação. Adapte duração, sobreposição, ordem e nomenclatura ao contexto. Os únicos decision gates canônicos são G0–G7; nem este programa nem um piloto são requisitos universais.

Objetivo

Dar forma de programa ao que o implementation playbook define como decisões. As fases organizam tempo, equipe e entregáveis; os gates G0–G7 continuam sendo o que autoriza avançar.

Para uma organização que adote este pattern, uma fase pode terminar sem que o gate correspondente seja aprovado. Quando isso acontece, o escopo não avança: o gate manda, o calendário não.

Fases e gates

Fase	Semanas	Objetivo	Entregáveis	Gate correspondente
F0 — Mobilizar	1–2	mandato e escopo	charter, scope statement, decision principles, fóruns, time do programa	G0
F1 — Descobrir	3–5	baseline real	discovery do estate, forecast, gargalos manuais, capability map, maturity baseline	G1
F2 — Desenhar	6–8	target operating model	target de maturidade, tiers calibrados, triggers de RAI, operating model, patterns de referência	G3 e preparação de G4
F3 — Construir	9–12	controles de fundação	registry, padrões de identidade, catálogos de dados e tools, schema de telemetria, MPB, runbooks iniciais	G2 e G4
F4 — Validar	13–16	validar ponta a ponta	piloto opcional, cohort de onboarding ou estate existente; fluxo risco→RAI→publicação, observabilidade, tabletop e KPIs	G5 e G6
F5 — Escalar	17–20	automação e cobertura	automação de discovery, policy-as-code, JML, attestation, baselines de comportamento, FinOps, dashboards	G6
F6 — Institucionalizar	21–24	operação regular e assurance	evidência e assurance, enablement, handoff para BAU, cadência de governança, roadmap de 12 meses	G7

Repare que F2 fecha G3 e F3 fecha G2 — a ordem numérica dos gates não é a ordem de execução. G3 exige apenas que G2 esteja suficiente para atribuir responsabilidade, não completo, então as duas frentes correm em paralelo. A dependência real entre gates está declarada no playbook, e é ela que manda no cronograma.

A coluna "entregáveis" nomeia os artefatos por fase. O catálogo de artefatos os detalha um a um, com propósito, owner típico e onde cada um está definido no corpus.

O roadmap de 90 dias é uma referência acelerada — corresponde aproximadamente a F0–F3 comprimidas. Este programa é uma referência mais detalhada. Os dois são guias adaptáveis do mesmo conjunto de gates, não métodos concorrentes nem prazos de compliance.

F0 — Mobilizar (semanas 1–2)

1. Entrevistar sponsors e validar problema e mandato.
2. Produzir charter, scope statement e princípios de decisão.
3. Definir fóruns de governança, presidências, decision rights e cadência.
4. Nomear program manager e leads de domínio.
5. Montar o corpus de referência e a baseline de standards aplicáveis.

Critério de saída: existe autoridade para definir requisitos, exigir evidência e conter sistemas fora do envelope aprovado. Sem isso, não automatize aprovações nem prometa cobertura.

F1 — Descobrir (semanas 3–5)

1. Executar discovery do estate em fontes técnicas e por entrevistas.
2. Produzir forecast de 6, 12 e 24 meses com mix de risco.
3. Mapear gargalos manuais e padrões de shadow AI.
4. Executar capability map e maturity assessment com evidência.
5. Publicar baseline, principais riscos e nível de confiança.

Critério de saída: o baseline separa o observado da hipótese, tem data de corte e todo gap crítico tem owner.

F2 — Desenhar (semanas 6–8)

1. Definir target de maturidade por capability — não nível máximo em tudo.
2. Calibrar tiers, scoring e escaladores com casos reais.
3. Desenhar operating model, RACI e handoff matrix.
4. Definir a integração risco → impact trigger → RAI → domain reviews → gate de publicação.
5. Aprovar arquitetura de referência e patterns por tier.

Critério de saída: cada decisão material tem accountable, receptor, prazo e escalation.

F3 — Construir (semanas 9–12)

1. Implementar o registry mínimo viável e os identificadores.
2. Implementar padrões de identidade e remediar credenciais compartilhadas na primeira cohort selecionada.
3. Criar o standard de dados AI-ready e o catálogo inicial de fontes certificadas.
4. Criar o registro de tools e a mediação para ações de alto impacto.
5. Implementar schema de telemetria, dashboards básicos, MPB e repositório de evidência.

Critério de saída: controles centrais demonstráveis em ambiente controlado ou por evidência operacional equivalente — não apresentados apenas em slide.

F4 — Validar (semanas 13–16)

Escolha uma rota de validação proporcional: piloto dedicado, cohort de onboarding, phased rollout ou avaliação retrospectiva de agentes já operacionais. O plano de piloto é um template útil quando a organização escolhe piloto; não é prerequisite deste programa.

1. Selecionar de 8 a 15 agentes cobrindo T1 a T3 e padrões arquiteturais distintos.
2. Executar o lifecycle completo de pelo menos um T2 e um T3.
3. Testar contenção de incidente e kill switch de verdade.
4. Rodar behavioral analytics em monitor-only.
5. Medir lead time, falsos positivos, fricção percebida e KPI de negócio.

Critério de saída: evidence suficiente para os gates G5/G6, controls ajustados e nenhum bloqueador crítico aberto. Se a rota escolhida for piloto, aplique também os critérios do plano de piloto.

F5 — Escalar (semanas 17–20)

1. Automatizar discovery, registro e policy gates simples.
2. Integrar JML, reatribuição de owner e workflow de dormancy.
3. Expandir fontes certificadas, tools e identidades próprias.
4. Calibrar detecções de comportamento e budgets de FinOps.
5. Expandir enablement e a rede de champions.

Critério de saída: metas de cobertura atingidas e gargalos manuais mensuravelmente reduzidos.

F6 — Institucionalizar (semanas 21–24)

1. Executar a revisão de evidência e assurance da primeira onda.
2. Transferir responsabilidades para a operação regular e documentar o modelo de suporte.
3. Publicar o governance dashboard e a cadência de fóruns.
4. Reavaliar maturidade e definir o target de 12 meses.
5. Planejar a automação restante com base nos dados da rota de validação escolhida.

Critério de saída: owners de BAU nomeados, cadência funcionando e próximos targets acordados.

Workstreams

Workstream é trilha de execução paralela dentro do mesmo roadmap — não um segundo cronograma.

Workstream	Lead típico	F0–F2	F3–F4	F5–F6
governança e risco	governança/risco	charter, tiers, triggers de RAI, operating model	workflow, evidência, reviews da primeira cohort	automação, assurance, exceções
arquitetura e plataforma	arquitetura/plataforma	patterns de referência	integração registry, runtime e policy	escala, resiliência, APIs
identidade e segurança	IAM/segurança	patterns e ameaças	identidade própria, controles, runbooks	JML, integração com SOC, tuning
dados e ferramentas	dados/API	desenho de standards e catálogos	fontes certificadas, tool registry	cobertura, remediação, recertificação
observabilidade e custo	SRE/FinOps	desenho da telemetria	dashboards, baseline, budget	automação de comportamento, unit economics
adoção e valor	negócio/change	portfólio, personas	enablement da primeira cohort, KPI	champions, operação regular, value review

Prioridade do backlog

P0 · P1 · P2 é prioridade de backlog, não severidade nem fase paralela. Cada item continua vinculado a uma fase, a um workstream, a dependências e a um critério de saída.

Prioridade	Significado	Exemplos
P0	obrigatório para iniciar a primeira release/cohort com segurança e rastreabilidade — sem isso o programa não deve se declarar pronto	charter, registry mínimo, tiers, blueprint, MPB, identidade para T2/T3, catálogos de fontes e ferramentas, logging, gate de publicação, kill switch, repositório de evidência
P1	necessário para escalar sem criar gargalo manual ou perda de controle	discovery automatizado, JML, automação de attestation, integração com SOC, behavioral analytics, dashboard de custo, policy-as-code, rede de champions
P2	otimização e automação avançada; antecipável quando houver dependência ou risco específico	scoring assistido, routing de modelos, detecção de duplicidade, grafo entre agentes, atribuição avançada de valor, remediação automática

Um item de backlog de qualidade

Campo	Exemplo
outcome	100% dos T2/T3 com identidade própria correlacionada ao registry
por quê	eliminar credencial compartilhada e habilitar atribuição e baseline de comportamento
dependências	agent_id no registry, API de IAM, dados de owner, eventos de lifecycle
trabalho	standard, workflow de provisionamento, migração, JML, enriquecimento de telemetria
evidência	export de registry e IAM mostrando cobertura; teste de revogação
critério de saída	zero credencial compartilhada em T2/T3 sem exceção; 100% com owner válido

Dependências entre workstreams

Workstreams distribuem execução, mas não podem otimizar localmente. Identidade pode declarar "entregue" enquanto o registry ainda não associa identidade a agent_id: tecnicamente há entrega, operacionalmente a capacidade continua incompleta.

Behavioral analytics depende de registry (identificar o ativo), identidade (atribuir a ação), telemetria (coletar as features) e runtime (responder ao desvio). Faltando qualquer uma, o backlog prioriza fundação — e essa relação precisa aparecer no plano integrado, não em listas separadas de cada time.

Milestones se definem por outcome cross-domain, não por entrega de trilha.

Cadência

Frequência	Fórum	O que decide
semanal	workstream	entregas, dependências e bloqueios
quinzenal	revisão integrada de arquitetura e governança	outcomes cross-domain
mensal	sponsor e council	risco, prioridade, funding e exceções
trimestral	revisão de maturidade	alvo e ajuste do roadmap

Depois do horizonte de referência — ciclo de melhoria contínua

O framework não pode ficar estático enquanto agentes, modelos e protocolos evoluem. Mudança de policy precisa ser impulsionada por evidência: incidentes, exceções, falsos positivos, novos padrões de ataque, anomalias de custo, lacunas de maturidade, feedback de builders e mudança regulatória.

Ciclo trimestral:

1. Revisar KPIs, KRIs e tendências do estate.
2. Analisar principais incidentes, quase-incidentes e eventos de quarentena.
3. Revisar exceções e verificar se viraram padrão legítimo ou dívida de governança.
4. Avaliar falsos positivos e negativos das regras de comportamento e dos policy gates.
5. Revisar gargalos manuais e oportunidades de automação.
6. Atualizar standards com changelog e data de vigência.
7. Priorizar as próximas capacidades no roadmap de maturidade.

O item 3 é o mais revelador: uma exceção que se repete não é exceção — é requisito que a policy ainda não reconheceu, ou controle que a operação não consegue cumprir. Os dois casos exigem mudança, não renovação.

Sinais de maturidade adaptativa

• mudanças de policy são baseadas em dados de runtime e resultados de risco;
• novos agentes são descobertos e registrados automaticamente;
• mudança material dispara reavaliação proporcional;
• sinais de comportamento reduzem capacidade ou exigem step-up automaticamente, com override governado;
• custo e valor orientam retirada e arquitetura;
• evidência é produzida continuamente, não preparada para a auditoria.

Como usar sem virar teatro de programa

• fases podem se sobrepor; gates não;
• prazo cumprido com evidência ausente é hold, não approve;
• escopo reduzido é decisão legítima e registrada, não fracasso silencioso;
• as 24 semanas dimensionam esforço, não prometem maturidade — maturidade se demonstra por evidência de operação, conforme o maturity model.
• encurtar, estender ou substituir fases é legítimo quando rationale, dependências e evidências permanecem explícitos.

O que este programa não faz

• não substitui análise jurídica ou regulatória;
• não define threshold universal;
• não seleciona produto;
• não impõe calendário, piloto ou ordem universal;
• não comprova maturidade por documentação;
• não certifica conformidade;
• não promete resultado financeiro.

Fonte: docs/guides/pilot-plan.md

Commit de origem: 5545d9227624400ab8bb707b6032b2f61329a36e.

Título controlado na origem: Plano opcional de piloto e critérios de expansão

Plano opcional de piloto e critérios de expansão

Uso opcional. Este documento é um template para organizações que escolhem um piloto porque precisam aprender em ambiente delimitado. Cohort de onboarding, phased rollout ou evidência de agentes existentes podem cumprir o mesmo objetivo. G0–G7, MPB e evidence requirements continuam iguais em qualquer rota.

Objetivo

Quando escolhido, o piloto existe para testar a governança, não para provar que um modelo de linguagem funciona.

Se todos os casos-piloto forem de leitura, a organização não valida identidade própria, mediação de ferramentas, oversight humano, rollback, quarentena, evidence pack ou resposta a incidente — e conclui, erradamente, que está pronta.

Coorte

Selecione de três a quatro casos que forcem rotas diferentes do framework.

Coorte	O que valida	Exemplo
T1 fast path	discovery, registro automático e rota self-service	assistente pessoal de conhecimento
T1 revisado	ownership de time e fonte de dados certificada	perguntas e respostas sobre procedimentos de uma área
T2	transação e governança de ferramentas	agente que abre e atualiza chamados
T3	assurance completo e aprovação humana	agente que propõe mudança material e executa após aprovação

Como regra de aprendizagem, não comece por T4: primeiro demonstre fundações e containment em casos menos críticos. Exceções são legítimas quando o primeiro caso real já é T4 ou quando a criticidade exige validação imediata; nesse cenário, aplique authority e controls de T4 desde o início. T4 não é sinônimo de restricted.

Desenho

1. Selecionar a coorte cobrindo leitura, transação e alto impacto.
2. Congelar baseline de processo, custo e qualidade antes do go-live — sem isso, não há como atribuir resultado depois.
3. Executar o fluxo completo: intake → risco → blueprint → build → reviews → MPB → publicação → observação → attestation ou mudança → simulação de suspensão e retirada.
4. Medir lead time e retrabalho da governança, além da performance do agente.
5. Executar ao menos um tabletop de incidente e um teste real de kill switch e quarentena.
6. Rodar behavioral analytics em monitor-only e FinOps por tarefa e resultado.
7. Coletar feedback separado de builder, reviewer, owner e operador — os quatro enxergam fricções diferentes.
8. Ajustar standards e thresholds antes de escalar, documentando o que mudou e por quê.

O que medir

Dimensão	Indicador
fricção	lead time por etapa e por tier; retrabalho de review
cobertura	completude do registry e do evidence pack
contenção	tempo até quarentena; sucesso do rollback
detecção	falsos positivos das regras de comportamento
economia	custo por resultado bem-sucedido contra baseline
resultado	KPI de negócio do caso, contra baseline congelada
experiência	percepção de builder, reviewer, owner e operador

Critérios de expansão quando a rota escolhida é piloto

Se a organização escolheu piloto, não escale a cohort antes de todos serem verdadeiros:

• nenhum finding crítico aberto; findings altos apenas com residual risk aceito pela authority correta;
• lead time de T1 baixo o suficiente para que contornar a governança não compense;
• T2 e T3 com identidade, evidência e telemetria completas;
• kill switch, quarentena e rollback funcionaram no teste — não em documentação;
• falsos positivos das regras de comportamento compreendidos e ajustados;
• custo e resultado efetivamente mensuráveis;
• owners de operação regular aceitaram a responsabilidade operacional, nominalmente.

O último item é o mais ignorado e o que mais derruba programas: sem owner de BAU aceito, o piloto vira uma ilha mantida pelo time do programa.

Relatório de piloto

O relatório fecha o ciclo e alimenta a decisão de expansão. Deve conter: objetivos; coorte; baseline congelada; controles efetivamente exercitados; gaps encontrados; lead time por etapa; exceções abertas; resultado do tabletop e do teste de contenção; achados de telemetria e comportamento; custo e valor; mudanças recomendadas nos standards; e a decisão registrada de approve, condition ou hold para a próxima onda.

Failure modes

• piloto só com casos de leitura, gerando falsa sensação de maturidade;
• medir apenas a performance do agente e nunca a fricção da governança;
• go-live sem baseline congelada — resultado sem atribuição possível;
• kill switch testado em documento;
• ajustar standards depois de escalar, quando o custo da mudança já multiplicou;
• piloto sem owner de operação regular designado;
• tratar ausência de incidente no piloto como prova de segurança.

Decision gate

Quando houver piloto, a expansão para a próxima onda exige relatório com decisão registrada, critérios atendidos e mudanças de standard incorporadas e versionadas. Sem piloto, a organização precisa apresentar evidência equivalente da primeira cohort, phased rollout ou operação existente; o gate avalia a qualidade da evidência, não o nome da rota.

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.