Governação é um sistema de decisão
Uma política só é útil quando esclarece quem pode iniciar, aprovar, rever, suspender e terminar um sistema. O desenho deve acompanhar o ciclo de vida, do primeiro teste à operação.
Classificar por impacto
Nem todos os usos precisam do mesmo controlo. Considere pessoas afetadas, reversibilidade, sensibilidade dos dados, autonomia, escala e contexto regulatório. Casos de maior impacto exigem evidência e revisão mais fortes.
Permissões, não instruções
Uma instrução vive na memória de trabalho do sistema; um acesso vive na sua configuração. Um sistema pode ignorar uma instrução — não pode usar um acesso que não existe. Por isso, uma governação séria não pergunta o que foi pedido ao sistema. Pergunta o que ele consegue alcançar, mesmo por engano. Regras de conduta governam intenções; acessos delimitados governam consequências.
- O que pode ler. O risco não é a leitura — é para onde a informação viaja a seguir: um resumo enviado para fora, um registo com as permissões erradas, uma pergunta que outra pessoa faz ao mesmo sistema mais tarde.
- O que pode alterar, enviar ou publicar. A maioria dos incidentes nasce aqui, porque o efeito sai do sistema e nem sempre é reversível. A pergunta certa não é se o sistema consegue fazê-lo — é o que acontece se o fizer no momento errado.
- O que pode gastar. Chega sempre a um extrato, e um pedido de desculpa não o desfaz. Precisa de um limite fixo, definido abaixo do que pareceria razoável à primeira vista, e revisto ao fim de um mês de operação real.
Regras de acesso, na prática
Ninguém entrega a um novo colaborador o acesso à conta bancária da empresa no primeiro dia de trabalho. Dá-lhe um login próprio, um conjunto limitado de ferramentas e supervisão sobre o que toca clientes — alargando a fronteira à medida que a confiança se confirma. Um sistema merece exatamente a mesma disciplina, nunca menos.
- Identidade própria para cada sistema — nunca as credenciais de uma pessoa.
- Leitura por defeito; escrita conquistada, não assumida à partida.
- Acessos mínimos para a função e revogáveis individualmente, sem desligar o resto.
- Registo de todas as ações — sem ele, cada incidente começa como um exercício de adivinhação.
Criar um registo vivo
Uma empresa que não consegue listar o que tem em produção não é dona do que tem em produção — apenas hospeda automações que ninguém sabe explicar de memória. O registo existe para responder, linha a linha, a uma pergunta simples: se isto avariar às 17h de sexta-feira, quem atende o telefone?
- O que faz, numa frase — sem jargão interno que só quem construiu entende.
- Onde vive: plataforma, conta, ambiente.
- O que pode tocar: o que lê, o que altera ou envia, o que gasta.
- Com que frequência corre e quanto custa operar.
- Quem é o responsável — uma pessoa com nome, não uma equipa.
- Onde ficam os registos de execução e quem pode consultá-los.
- Como se desliga, e quem tem autoridade para o fazer sem pedir licença.
Desenhar supervisão humana
Supervisão não é uma propriedade do sistema — é uma propriedade de cada etapa dentro dele. Atribua a cada etapa um nível explícito, do controlo total à execução autónoma, comece sempre no nível mais baixo que ainda resolve o problema, e só suba com evidência acumulada — nunca porque a demonstração correu bem ou porque a equipa está entusiasmada.
- Cada etapa avança um degrau de cada vez, com uma paragem clara entre níveis — nunca um salto direto do controlo manual para a execução sem supervisão.
- Execução sem intervenção não significa sem vigilância: exige registos, indicadores, alertas e condições de paragem definidos antes de correr, não depois do incidente.
- Poucos alertas, e bem escolhidos. Um alerta para tudo é um alerta para nada — a equipa aprende a ignorá-lo.
- Comunicação pública, reporte financeiro e documentos legais não sobem de nível por definição: o sistema pode preparar, uma pessoa mantém a decisão de enviar.
- Um sistema com dez mil respostas certas ainda vai produzir uma errada. Onde essa resposta é irreversível, uma é suficiente para justificar o controlo permanente.
Sequência de incidente
Um incidente não pede heroísmo, pede sequência. Comece pelo passo mais reversível e só avance se o anterior não resolveu.
- Pausar novas entradas — parar o que chega a seguir, sem tocar no que já correu.
- Ler os registos. A maioria dos incidentes resolve-se aqui: o que parecia grave na primeira mensagem costuma ser mais pequeno visto nos logs.
- Revogar apenas o acesso implicado — uma chave sai do molho, o resto continua a correr.
- Corrigir a causa, quando a falha está na construção do sistema e não no acesso que lhe foi dado.
- Validar com casos de resposta já conhecida antes de voltar a tocar em trabalho novo.
- Reiniciar mais pequeno, ou desligar. Desligar um sistema que não paga o que custa operar é uma decisão correta, não um fracasso.
Preparar o AI Act
O Regulamento Europeu da Inteligência Artificial utiliza uma abordagem baseada no risco e distribui obrigações por diferentes papéis. A classificação e as datas aplicáveis devem ser confirmadas com fontes oficiais e aconselhamento jurídico; este guia não substitui essa análise.
- Inventariar sistemas e fornecedores.
- Identificar o papel da organização em cada utilização.
- Recolher documentação e evidência operacional.
- Definir revisão jurídica para casos relevantes.
Um modelo de política que define decisões
Uma política útil não é uma lista de princípios abstratos. Deve dizer que utilizações são assistivas, quais exigem revisão e quais ficam proibidas sem avaliação formal. Deve ainda identificar owners, evidência mínima, incidentes, exceções e autoridade para suspender um sistema.
O modelo abaixo é editável e foi desenhado para uma primeira sessão de trabalho entre negócio, tecnologia, segurança, privacidade e risco. Não certifica conformidade e não substitui revisão jurídica.
Versão 1.0 · 25/08/2026 · utilização interna livre. O ficheiro inclui classes verde/âmbar/vermelho, registo de sistemas, fornecedores, supervisão, incidentes, literacia, exceções e changelog.
O que confirmar em fontes oficiais
A política interna deve remeter para análise competente quando uma utilização pode envolver obrigações legais. O texto consolidado do Regulamento Europeu de IA, a cronologia de aplicação e as orientações de transparência mudam; confirme sempre a versão e a data antes de decidir.
- Regulamento (UE) 2024/1689 no EUR-Lex.
- Cronologia oficial do AI Act da Comissão Europeia.
- Enforcement e obrigações em aplicação.
Para perceber se estes controlos existem na prática, use o perfil de maturidade; a dimensão de governação exige evidência observável, não apenas uma política publicada.
Os níveis de supervisão descritos nesta página ganham forma concreta no modelo operativo, que liga decisão, execução e responsabilidade num único desenho.
Revisto em 25/08/2026. Este conteúdo é um framework de governação e não aconselhamento jurídico.