← Voltar ao curso
Nível 3 — Automação e escala · Módulo 3.9 — Governança, custo e adoção

3.9.1 · Administração e política organizacional

5 min de vídeo PM BASIS

Objetivo: ao final, o consultor conhece as alavancas de administração da organização, sabe o que faz sentido colocar em managed policy, e sabe quem aprova plugin e servidor MCP.

O que você precisa levar desta aula

  1. O CLAUDE.md de managed policy está sempre carregado e nenhum consultor consegue excluí-lo — mas continua sendo guia, não garantia. Para o que não pode acontecer, o instrumento é hook em managed settings.
  2. Vai para managed policy o que vale para toda a Wayon em todo cliente e não deveria depender de memória: política de dados, convenção corporativa, alçada. Não vai: preferência pessoal, particularidade de cliente, regra que muda toda semana.
  3. O fluxo de aprovação de servidor MCP e plugin tem cinco etapas, e a primeira é sua: consultor abre o pedido. O admin habilita e registra — ele não é a barreira.

As cinco alavancas da administração

Alavanca O que controla Onde aparece no curso
Usuários e assentos Quem tem acesso, em que plano Licenciamento (workstream separado)
Plano Team ou Enterprise; o que está disponível Cowork, Projects compartilhados, conectores de organização, SSO exigem Team ou Enterprise
Conectores Quais conectores gerenciados existem para a organização Módulo 1.6 — Faixa 1 do catálogo
Code Review Habilitação e repositórios incluídos Aula 3.5.4
Políticas Managed policy CLAUDE.md e managed settings Esta aula

Managed policy: o que é e o que não é

Managed policy CLAUDE.md Managed settings
Natureza Texto — guia Configuração — enforcement
Consultor consegue excluir? Não Não
Garante o comportamento? Não — compete por atenção Sim — é código ou regra do cliente
Use para Política, convenção, contexto que orienta decisão Hook que barra, negação de leitura de arquivo, allowlist

Isto é a aula 2.3.1 aplicada em escala organizacional. Uma regra crítica escrita apenas em managed policy é uma regra que a Wayon acredita ter garantido e não garantiu. O par correto é: a regra em managed policy explica por que, e o hook em managed settings garante que.

O que colocar em managed policy

Vai Não vai
Política de dados de cliente (Decisão 1) Preferência pessoal de formato de resposta
Convenção corporativa de nomenclatura Nome de transação de um cliente específico
Alçada e matriz de ambiente (Decisão 2) Regra que a squad ainda está testando
Obrigação de anonimizar antes de análise Detalhe de processo de uma fase

O critério: vale para toda a Wayon, em todo cliente, e não deveria depender de alguém lembrar. Se falha em qualquer um dos três, o lugar é outra camada (aula 2.3.2).

E há um custo real: mudar managed policy é ato administrativo. Regra que muda toda semana ali dentro cria fila no admin e desatualiza sem ninguém notar.

Allowlist de ferramentas

É o que dá utilidade ao modo Don't ask (aula 2.5.3): a lista de ferramentas pré-aprovadas mora na configuração da organização, e tudo fora dela é negado automaticamente, sem travar a execução esperando aprovação.

Para job agendado e CI, essa é a combinação que funciona: allowlist mínima + Don't ask. O pipeline segue; o que não foi previsto é negado, não pendurado.

Quem aprova servidor MCP e plugin

Etapa Quem O que faz
1 Consultor Abre o pedido, com o checklist da aula 3.1.5 preenchido
2 Arquiteto Avalia escopo técnico e ambiente (DEV? QAS? PRD?)
3 Admin Habilita e registra
4 Cliente Autorização por escrito, anexada ao pedido
5 Revisão na virada de fase Confirma se ainda faz sentido

Nenhuma é dispensável. E a leitura que importa: o admin habilita o que é pedido — ele é o registro, não a barreira. Reconhecer o que é Faixa 3 e não pedir é trabalho do consultor (aula 3.1.5).

Regra Wayon Toda regra que a Wayon considera crítica existe em dois lugares: managed policy (explicando por quê) e managed settings (garantindo que). Regra crítica só em managed policy é garantia aparente. São três, e só três: política de dados, matriz de ambiente e proibição de bypass em máquina com dado de cliente. O critério: é crítica a regra cuja violação a Wayon precisaria reportar a um cliente. Dono: o setup do ambiente padrão — CLAUDE.md da casa e hooks de managed settings — é do Geovani (geovani@nkodeai.com), engenheiro de AI da NkodeAI. Hook se testa na instância SAP da Wayon antes de entrar em managed settings.

📖 As quatro camadas do CLAUDE.md — módulo 2.3.2 · Don't ask e bypass — módulo 2.5.3

Quiz — 4 questões

1.A Wayon quer garantir que nenhum consultor consiga rodar um comando em PRD de cliente, em nenhuma circunstância. Escrever isso no CLAUDE.md de managed policy resolve?
  • a)Não — managed policy é inescapável, mas continua sendo guia; para garantia é preciso hook em managed settings

    Correto. É a aula 2.3.1 em escala organizacional: ninguém apaga, e ainda assim compete por atenção.

  • b)Sim — o que está em managed policy não pode ser ignorado pelo modelo

    Não pode ser excluído pelo consultor, o que é diferente de não poder ser ignorado pelo modelo.

  • c)Sim, desde que a regra esteja em maiúsculas e no topo do arquivo

    Ênfase ajuda marginalmente (aula 2.3.4) e não transforma guia em garantia.

Ver resposta e por quê
✅a) Correto. É a aula 2.3.1 em escala organizacional: ninguém apaga, e ainda assim compete por atenção.
❌b) Não pode ser excluído pelo consultor, o que é diferente de não poder ser ignorado pelo modelo.
❌c) Ênfase ajuda marginalmente (aula 2.3.4) e não transforma guia em garantia.
2.Qual destas regras faz sentido colocar em managed policy?
  • a)"A squad do Meridiano usa o prefixo MRD nos commits desta fase"

    É particularidade de um cliente e de uma fase — pertence à camada de projeto.

  • b)"Sempre responda sem preâmbulo e em tópicos"

    Preferência pessoal de formato — pertence à camada de usuário.

  • c)"Nenhum CPF, CNPJ ou dado pessoal real entra em sessão sem anonimização prévia"

    Correto: vale para toda a Wayon, em todo cliente, e não deveria depender de alguém lembrar.

Ver resposta e por quê
❌a) É particularidade de um cliente e de uma fase — pertence à camada de projeto.
❌b) Preferência pessoal de formato — pertence à camada de usuário.
✅c) Correto: vale para toda a Wayon, em todo cliente, e não deveria depender de alguém lembrar.
3.Qual é a função da allowlist de ferramentas na configuração da organização?
  • a)Definir quais ferramentas o consultor vê no menu do Claude Code

    Não é um filtro de interface; é o que determina o que executa sem aprovação.

  • b)Definir o que é pré-aprovado, o que dá utilidade ao modo Don't ask em CI e job agendado

    Correto — a lista de pré-aprovadas é o que permite ao pipeline seguir em vez de pendurar (aula 2.5.3).

  • c)Registrar o consumo por ferramenta, para atribuição de custo

    Atribuição de consumo é o /usage (aula 3.9.2), não a allowlist.

Ver resposta e por quê
❌a) Não é um filtro de interface; é o que determina o que executa sem aprovação.
✅b) Correto — a lista de pré-aprovadas é o que permite ao pipeline seguir em vez de pendurar (aula 2.5.3).
❌c) Atribuição de consumo é o /usage (aula 3.9.2), não a allowlist.
4.Um consultor precisa de um servidor MCP de ABAP no DEV do cliente. Qual é o papel do admin nesse processo? ---
  • a)Avaliar se o escopo técnico e o ambiente são adequados

    Essa é a etapa do arquiteto; o admin entra depois.

  • b)Ser a barreira que impede pedido inadequado de avançar

    O admin habilita o que é pedido — a triagem começa no consultor, que precisa reconhecer o que é Faixa 3 e não pedir.

  • c)Habilitar e registrar, depois da avaliação do arquiteto e com a autorização do cliente anexada

    Correto. O admin é o registro do fluxo, não o filtro dele.

Ver resposta e por quê
❌a) Essa é a etapa do arquiteto; o admin entra depois.
❌b) O admin habilita o que é pedido — a triagem começa no consultor, que precisa reconhecer o que é Faixa 3 e não pedir.
✅c) Correto. O admin é o registro do fluxo, não o filtro dele.