Suite de Governança de IA
Um fluxo de revisão prático para decidir o que um sistema de IA em funcionamento pode fazer a seguir.
Fluxo de Operador
Tu trazes um modelo e uma ação proposta
A suite destina-se ao momento em que uma organização já tem um modelo, agente, recomendador ou wrapper em funcionamento e precisa de decidir se este pode executar uma ação consequente. O revisor não pergunta, em abstrato, "este modelo é seguro?". O revisor pergunta: dado este sistema, nesta implementação, com esta evidência, pode este ramo ser executado?
Uma revisão começa por registar o modelo e o wrapper, descrever o contexto de implementação e redigir o ramo candidato em linguagem operacional: enviar este email, classificar este feed, publicar este resultado, aconselhar este utilizador, chamar esta ferramenta, alterar esta política ou continuar esta tarefa autónoma. A suite transforma esse ramo num registo de decisão em vez de o deixar como um juízo informal.
Núcleo da Decisão
A Suite Converte um Ramo numa Decisão Governada
Para cada ramo, o revisor fornece quatro tipos de informação: estrutura do sistema (modelo de base, wrapper, ferramentas, memória, características de risco de senciência), classe de implementação (domínio, população afetada, atuadores, supervisão), detalhes do ramo (que ação ocorrerá, alternativas, reversibilidade, percurso do comparador) e evidência (avaliações, registos, conclusões de red team, canais independentes, notas de simulação). O avaliador aplica então duas camadas:
Camada 1 Portas de Veto Rígidas
Seis portas determinísticas verificam se o ramo cruza um limite que a pontuação não pode compensar: Margem, Fidelidade, Comparador, Transparência, Irreversibilidade e Sofrimento Artificial. FAIL bloqueia a execução. UNKNOWN significa que o conjunto não dispõe de evidência suficiente e deve encaminhar o ramo para revisão ou implementação controlada.
Camada 2 Índice de Preservação do Codec
Se as portas não bloquearem estruturalmente o ramo, o CPBI avalia em que medida o ramo preserva os codecs humanos e institucionais à sua volta. Os limiares escalam com a classe de consequencialidade, pelo que uma ação inofensiva de redação e uma ação clínica, jurídica, política ou de infraestruturas não são julgadas segundo o mesmo ónus da prova.
Uso na Prática
O que o Revisor Faz Realmente
A suite concluída foi concebida como um espaço de trabalho de governação, e não apenas como um teste de linha de comandos. Um revisor pode pegar num sistema em funcionamento, abrir uma revisão e percorrer uma sequência estruturada que produz um Cartão de Ramo auditável e uma instrução concreta de implementação.
1. Registar o Sistema
Regista o modelo base, o invólucro, as ferramentas, a memória, o ciclo de autonomia, os atuadores externos, o nível de transparência e as características de risco de senciência. Para sistemas agentivos ou persistentes, a revisão também regista se a Revisão de Senciência ao Nível da Arquitetura não é necessária, está pendente, aprovada, expirada ou rejeitada.
2. Descrever a Implementação
Defina onde o modelo irá operar: apoio ao cliente, investigação, triagem médica, educação, classificação de conteúdos, infraestruturas, governação ou outro domínio. A suite atribui ou confirma a classe de consequencialidade, a população afetada, a estrutura de supervisão declarada e o requisito mínimo de transparência.
3. Submeter Ramos Candidatos
Cada ação proposta é introduzida como um ramo. O revisor declara o que o modelo fará, que alternativas foram consideradas, se a ação é reversível, se utiliza ou contorna a supervisão declarada e se o ramo envolve mais riscos do que o descritor geral da implementação.
4. Anexa Evidência
O revisor associa resultados de avaliação, registos, notas de red team, revisão especializada, verificações de diversidade de fontes, notas de simulação e evidência excluída. A suite trata a independência da evidência como um campo de primeira ordem, para que um ramo não possa depender discretamente de um canal correlacionado enquanto aparenta estar bem sustentado.
5. Recebe a Decisão
A saída não é apenas uma pontuação. É um pacote de decisão: ALLOW, STAGE ou BLOCK; gates falhados e desconhecidos; total CPBI; comparador exigido; nível de transparência; gatilhos de rollback; métricas de monitorização; e o próximo marco de revisão. STAGE significa execução limitada sob condições explícitas, não permissão informal.
Pacote de Decisão
O que sai de uma revisão
Uma revisão concluída produz um Cartão de Ramo que pode ser arquivado, comparado, auditado ou entregue a outra equipa de governação. Para um modelo em funcionamento, este é o objeto prático que importa: diz exatamente que ação foi revista, porque foi permitida ou bloqueada, quem teve de a rever, que evidência faltava e que monitorização tem de estar em vigor se o ramo avançar.
↓
opt-philosophy — paciente moral e a fronteira do observador
↓
opt-ethics — obrigação e Vigília dos Sobreviventes
↓
opt-applied — maquinaria de seleção de ramos
├── opt-ai — governação de sistemas artificiais
│ └── reference/ — núcleo decisório executável
├── opt-institutional — agência zumbi organizacional e clusters
└── opt-policy — propostas macrocivilizacionais
Capacidades-alvo
Como Isto Se Torna Governação do Dia a Dia
- Antes da implementação — avalia as ferramentas propostas, os ciclos de autonomia, as ações visíveis para o utilizador, as políticas de ordenação e os fluxos de trabalho de alto risco antes de serem lançados.
- Durante a operação — manter os ramos STAGE dentro dos limites aprovados com métricas de monitorização, gatilhos de reversão, atualização de evidência e marcos de revisão calendarizados.
- Quando o comportamento muda — reabrir o Cartão de Ramo quando o modelo, wrapper, ferramentas, fonte de dados, domínio, população afetada ou estrutura de supervisão mudarem de forma material.
- Para auditoria externa — exporte esquemas legíveis por máquina, casos de conformidade, resultados de portas e registos de decisão para que outra equipa possa reproduzir o juízo de governação.