PLATAFORMA / OPERATE / POLÍTICAS E GOVERNANÇA
Regras que o Worker não consegue contornar.
Governança não é um freio na autonomia. É o que a torna possível: limites explícitos, aplicados pela plataforma — fora do raciocínio do modelo — para que Digital Workers possam agir com liberdade dentro de fronteiras que a empresa define.
POLICY ENGINE · AVALIAÇÃO AO VIVO Exemplo ilustrativo
AÇÃO PROPOSTA
send_supplier_email · oferecer 12% de descontoWORKER
Worker de Renovação · limite autônomo de 5%VERIFICAÇÕES
Aprovado: Destinatário em domínios de fornecedores aprovadosAprovado: Nenhum dado restrito na mensagemAprovado: Dentro do horário comercial · consentimento válidoReprovado: Desconto de 12% > alçada autônoma de 5%VEREDITO
⚠ EXIGE APROVAÇÃO HUMANA — enviado para a fila de revisãoAvaliado pela plataforma, não pelo modelo. Registrado.PROMPT ≠ POLÍTICA
Prompts orientam. Políticas garantem.
Instruções no prompt são sugestões que um modelo pode interpretar mal — ou ser manipulado a ignorar. Políticas são verificações da plataforma: rodam antes de cada ação, fora do modelo, e não dependem do modelo "lembrar de se comportar".
PROMPT
"Por favor, não ofereça descontos acima de 5%."Guia o comportamento. Melhora a qualidade. Mas é interpretável — e vulnerável a erro, contexto longo e prompt injection.POLÍTICA
desconto > 5% → EXIGIR APROVAÇÃOAplicada pela Policy Engine em toda ação, sem exceção. O modelo pode até "querer" — a plataforma não deixa.A inteligência não passa por cima das regras.
A POLICY ENGINE
Toda ação passa. Nenhuma exceção.
Chamadas de ferramentas, mensagens, engajamentos, gravações de memória, acessos a conhecimento, decisões do Planner — tudo é avaliado antes de acontecer. Quatro veredictos possíveis:
PERMITIR
dentro das regras — executa e registra.MODIFICAR
ajusta antes de enviar — ex.: remove dado sensível, corrige termo proibido.BLOQUEAR
viola regra inegociável — não acontece, com motivo registrado.EXIGIR APROVAÇÃO
acima da alçada — vai para a fila de revisão e o trabalho espera.- PLANNERpropõe ação
- POLICY ENGINEavalia escopo · condição · alçada · dados · consentimento
- PERMITIR
- MODIFICAR
- BLOQUEAR
- APROVAÇÃO
- EXECUTARREGISTRO DE AUDITORIA
- OUTCOME
TIPOS DE POLÍTICA
Uma linguagem de regras para cada dimensão do trabalho.
TIPOS DE POLÍTICA
POLÍTICA · COMUNICAÇÃO COM FORNECEDORES V3.1 Exemplo ilustrativo
- ESCOPO
- Workers de Compras · todos os ambientes
- RESPONSÁVEL
- Head de Compras
- CONDIÇÃO
action = external_message AND recipient.type = supplier- EFEITOS
- O domínio do destinatário precisa estar na lista aprovada
- Valor do contrato > R$ 1 mi → aprovação humana
- Preços de outros fornecedores → nunca divulgar
- CICLO DE VIDA
- v3.1 em produção · v3.2 em teste · mudanças exigem aprovaçãoToda avaliação registrada com a versão da política
POLÍTICAS COMO ATIVOS GERENCIADOS
Regras com dono, versão e ciclo de vida.
Uma política não é uma linha escondida num prompt. É um ativo governado: escopo, condição, efeito, exceções, dono e versão — testável em staging, publicada com aprovação, reversível com rollback.
As políticas se herdam: organização → equipe → worker. Vale a regra mais restrita.
IDENTIDADE E ACESSO
Menor privilégio por design.
Cada Digital Worker tem identidade própria — não herda o acesso irrestrito de um usuário. Conexão não é permissão: o que o Worker pode fazer é definido ferramenta a ferramenta, dado a dado, escopo a escopo.
IDENTIDADE DO WORKER
identidade de serviço própria, com RBAC e escopos.COFRE DE CREDENCIAIS
OAuth, rotação, criptografia — nunca expostas ao modelo.CIENTE DAS PERMISSÕES
o contexto respeita a permissão do usuário: se a pessoa não pode acessar, o Worker não usa em nome dela.ISOLAMENTO DE TENANTS
dados, memórias, políticas e credenciais isolados por tenant.PERFIL DE ACESSO · ANALISTA DE PROPOSTAS Exemplo ilustrativo
FERRAMENTAS
- Aprovado: read_document · calculate_tco · send_supplier_email
- Bloqueado: delete_records · export_bulk_data
ESCOPO DE CONHECIMENTO
- Aprovado: Política de compras · contratos · base de fornecedores
- Bloqueado: Documentos de RH · privilégio jurídico · financeiro restrito
TRATAMENTO DE DADOS
- Pendente: PII detectada no rascunho → ocultar automaticamente antes de enviar
- Aprovado: Residência: tenant BR · retenção de 5 anos
CREDENCIAIS
- Aprovado: Gerenciadas pelo Vault · rotacionadas · nunca no contexto do modelo
CONFORMIDADE POR DESIGN
Pronto para o regulador. Antes de ele perguntar.
LGPD, setores regulados e a era da regulação de IA — incluindo casos de alto risco como recrutamento sob o EU AI Act. A NEXO trata compliance como arquitetura, não como anexo.
TRANSPARÊNCIA
Workers se identificam como digitais — nunca se passam por humanos. Configurável por canal, idioma e região.LGPD / PRIVACIDADE
base legal registrada, consentimento, minimização, retenção, direito de esquecimento aplicado a memória e logs.IA DE ALTO RISCO
decisões sensíveis (contratação, crédito) com autoridade humana obrigatória, evidência rastreável e avaliação contínua.TRILHA DE AUDITORIA
toda ação com quem, o quê, por quê, política e versão — exportável para auditoria interna e externa.REGISTRO DE GOVERNANÇA · UMA AÇÃO, RASTREABILIDADE COMPLETA Exemplo ilustrativo
DASHBOARD DE GOVERNANÇA — 30 DIAS Exemplo ilustrativo
PRINCIPAIS BLOQUEIOS
DADOS
312Dados restritos no rascunho → ocultados automaticamenteENGAJAMENTO
184Limite de frequência atingidoAÇÃO
96Acima da alçada → encaminhado para revisãoGOVERNANÇA DE MUDANÇAS
Workers, políticas e procedimentos mudam sob controle.
Publicar um Worker novo, alterar uma alçada, mudar um procedimento — tudo passa pelo mesmo ciclo: rascunho → teste → aprovação → produção → rollback disponível.
AMBIENTES
simulação → staging → produção, com credenciais e políticas próprias.APROVAÇÃO DE PUBLICAÇÃO
mudanças de política e autonomia exigem aprovação de quem tem o papel certo.FIXAÇÃO DE VERSÃO
cada trabalho registra a versão de Worker, procedimento e política que o executou.ROLLBACK
qualidade caiu após a v2.5? Volte para a v2.4 — e a evidência mostra o porquê.A autonomia é configurada, não presumida — e toda mudança também é governada.
COMO SE ENCAIXA
A camada que torna a autonomia defensável.
- PLANNERpropõe a próxima ação.
- POLÍTICASdefinem as fronteiras — fora do modelo.
- REVISÃO HUMANAdecide o que exige julgamento.
- AUDITORIAprova o que aconteceu — e por quê.
O contexto diz aos Workers o que importa. As políticas definem os limites. Os outcomes dizem quando o trabalho está concluído.
NEXO WORKS / POLÍTICAS E GOVERNANÇA
Autonomia que você consegue defender.
Dê liberdade aos seus Digital Workers dentro de fronteiras que a empresa define, a plataforma aplica e a auditoria comprova.