PLATFORM / OPERATE / POLICIES & GOVERNANCE
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 reasoning do modelo — para que Digital Workers possam agir com liberdade dentro de fronteiras que a empresa define.
POLICY ENGINE · LIVE EVALUATION Exemplo ilustrativo
PROPOSED ACTION
send_supplier_email · offer 12% discountWORKER
Renewal Worker · autonomous limit 5%CHECKS
Recipient in approved supplier domainsNo restricted data in messageWithin business hours · consent validVERDICT
⚠ REQUIRE HUMAN APPROVAL — routed to Review QueueAvaliado pela plataforma, não pelo modelo. Registrado.PROMPT ≠ POLICY
Prompts orientam. Policies garantem.
Instruções no prompt são sugestões que um modelo pode interpretar mal — ou ser manipulado a ignorar. Policies 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.POLICY
discount > 5% → REQUIRE APPROVALAplicada pela Policy Engine em toda ação, sem exceção. O modelo pode até "querer" — a plataforma não deixa.Intelligence doesn't override rules.
THE POLICY ENGINE
Toda ação passa. Nenhuma exceção.
Tool calls, mensagens, engagements, gravações de memória, acessos a conhecimento, decisões do Planner — tudo é avaliado antes de acontecer. Quatro veredictos possíveis:
ALLOW
dentro das regras — executa e registra.MODIFY
ajusta antes de enviar — ex.: remove dado sensível, corrige termo proibido.BLOCK
viola regra inegociável — não acontece, com motivo registrado.REQUIRE APPROVAL
acima da alçada — vai para a Review Queue e o trabalho espera.PLANNER proposes action
POLICY ENGINE
↓ evaluates scope · condition · authority · data · consentPOLICY TYPES
Uma linguagem de regras para cada dimensão do trabalho.
ACTION POLICIES
alçadas, limites de valor, ações proibidas, aprovações obrigatórias."PO acima de R$ 50k → aprovação · delete_records → nunca."
COMMUNICATION POLICIES
destinatários permitidos, termos proibidos, disclosure, tom aprovado."Somente domínios de fornecedores aprovados · 'garantia' → usar 'expectativa'."
DATA POLICIES
PII, classificação, escopo por Worker e por usuário, retenção.
"Dados de RH nunca entram no contexto do Proposal Analyst."
ENGAGEMENT POLICIES
consentimento, frequency caps, quiet hours, opt-out irreversível."Máx. 3 e-mails / 21 dias · sem contato 20h–8h · opt-out → STOP."
MEMORY POLICIES
o que pode ser gravado, com qual aprovação, TTL e escopo."Precedente de negociação → aprovação humana antes de virar memória organizacional."MODEL POLICIES
quais modelos para quais tarefas, dados e regiões."Documentos jurídicos → apenas modelos aprovados no tenant BR."DATA POLICIES
POLICY · SUPPLIER COMMUNICATION V3.1 Exemplo ilustrativo
SCOPE
Procurement Workers · all environmentsOWNER
Head of ProcurementCONDITION
action = external_message AND recipient.type = supplierEFFECTS
Recipient domain must be in approved listContract value > R$ 1M → human approvalPricing of other suppliers → never discloseLIFECYCLE
v3.1 production · v3.2 testing · changes require approvalToda avaliação registrada com a versão da políticaPOLICIES AS MANAGED ASSETS
Regras com dono, versão e ciclo de vida.
Uma policy 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.
SCOPE
a quem se aplica — Worker, time, tenant, ambiente.CONDITION
quando dispara — ação, valor, destinatário, dado, canal, horário.EFFECT
allow · modify · block · require approval.EXCEPTIONS
explícitas e auditáveis — nunca implícitas.VERSIONING
quem mudou, o quê, quando — e qual versão avaliou cada ação.Policies inherit: organization → team → worker. The strictest rule wins.IDENTITY & ACCESS
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 tool a tool, dado a dado, escopo a escopo.
WORKER IDENTITY
service identity própria, com RBAC e escopos.CREDENTIALS VAULT
OAuth, rotação, criptografia — nunca expostas ao modelo.PERMISSION-AWARE
o contexto respeita a permissão do usuário: se a pessoa não pode acessar, o Worker não usa em nome dela.TENANT ISOLATION Exemplo ilustrativo
IDENTITY & ACCESS
ACCESS PROFILE · PROPOSAL ANALYST Exemplo ilustrativo
TOOLS
read_document · calculate_tco · send_supplier_emaildelete_records · export_bulk_dataKNOWLEDGE SCOPE
Procurement policy · contracts · supplier DBHR documents · legal privileged · finance restrictedDATA HANDLING
PII detected in draft → auto-redact before sendResidency: tenant BR · retention 5 yearsCREDENTIALS
Vault-managed · rotated · never in model contextCONFORMIDADE 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.
DISCLOSURE
Workers se identificam como digitais — nunca se passam por humanos. Configurável por canal, idioma e região.LGPD / PRIVACY
base legal registrada, consentimento, minimização, retenção, direito de esquecimento aplicado a memória e logs.HIGH-RISK AI
decisões sensíveis (contratação, crédito) com human authority obrigatória, evidência rastreável e avaliação contínua.AUDIT TRAIL
toda ação com quem, o quê, por quê, política e versão — exportável para auditoria interna e externa.GOVERNANCE RECORD · ONE ACTION, FULL LINEAGE Exemplo ilustrativo
CONFORMIDADE POR DESIGN
GOVERNANCE DASHBOARD — 30 DAYS Exemplo ilustrativo
TOP BLOCKS
DATA
312Restricted data in draft → auto-redactedENGAGEMENT
184Frequency cap reachedACTION
96Above authority → routed to reviewCHANGE GOVERNANCE
Workers, policies e procedures mudam sob controle.
Publicar um Worker novo, alterar uma alçada, mudar um procedure — tudo passa pelo mesmo ciclo: draft → test → approval → production → rollback disponível.
ENVIRONMENTS
simulation → staging → production, com credenciais e políticas próprias.PUBLISH APPROVAL
mudanças de política e autonomia exigem aprovação de quem tem o papel certo.VERSION PINNING
cada trabalho registra a versão de Worker, procedure e policy 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.
PLANNER
propõe a próxima ação.POLICIES
definem as fronteiras — fora do modelo.HUMAN REVIEW
decide o que exige julgamento.AUDIT
prova 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 / POLICIES & GOVERNANCE
Autonomy you can defend.
Dê liberdade aos seus Digital Workers dentro de fronteiras que a empresa define, a plataforma aplica e a auditoria comprova.