Pular para o conteúdo

Guias

Jurisdições

Uma constatação lida por jurisdição é um auxílio de leitura tirado de catálogos em rascunho não revisados por um advogado. Nunca é aconselhamento jurídico nem uma afirmação de que um sistema cumpre uma lei; prevalece o texto oficial de cada instrumento. Declare onde um sistema é usado, e o Oloproof o lê diante de cada catálogo que cobre esse lugar, nomeia cada um que deixou de fora e por quê, e diz quando um catálogo deve ser relido.

Declarar onde um sistema é usado

Um sistema em governance.yaml pode declarar jurisdictions:, uma lista de códigos ISO 3166: um país (CA, US), uma subdivisão (CA-QC, US-CO), uma cidade depois da sua subdivisão (US-NY-NYC), EU ou INT. Acrescente sector: (public ou private) e role: (provider ou deployer) onde o alcance de um instrumento depender deles, e nomeie o índice de catálogos:

catalogue_index: catalogues/catalogues.yaml
systems:
  - id: triage
    name: Benefits triage
    in_scope: true
    scope_reason: assesses eligibility for a provincial benefit
    aia_level: II
    jurisdictions: [CA-QC]
    sector: public

oloproof governance check então acrescenta à lista do próprio sistema cada catálogo indexado que se aplica e imprime, por sistema, cada catálogo selecionado ou deixado de fora com o seu motivo: uma diretiva federal não alcança um órgão provincial, um setor ou papel que não corresponde é nomeado, um quadro voluntário é oferecido e nunca selecionado, e um instrumento proposto ou revogado é catalogado e nunca selecionado. Um catálogo proposto nomeado à mão é recusado em vez de avaliado. Um sistema sem jurisdições mantém os catálogos que ele mesmo nomeia. Quando todo sistema declara jurisdições, o arquivo pode não nomear catálogo algum e deixá-los ao índice, como acima; oloproof init --example governance escreve um projeto assim, com os catálogos e o seu índice copiados para catalogues/.

Um código só corresponde para baixo: um catálogo indexado para CA com subdivisões cobre CA-QC, mas um sistema que declara US-NY não é coberto por um catálogo para US-NY-NYC. Declare o lugar mais preciso onde o sistema é usado, e cada lugar onde ele é usado.

O que o índice contém

Cada entrada de catalogues.yaml nomeia um arquivo de catálogo, as jurisdições que ele cobre, se cobre suas subdivisões, e onde se aplica: sector, role, voluntary e status (in_force, proposed ou repealed), com uma note opcional que diz por que um instrumento proposto não é selecionado. Ele indexa o Canadá (a diretiva federal e sua avaliação de impacto algorítmico, a Policy on Service and Digital e sua orientação, o projeto de lei C-36, proposto), Quebec (suas leis de privacidade dos setores privado e público), Ontário (sua diretiva de IA e o Enhancing Digital Security and Trust Act, proposto até que um regulamento nomeie a quem seus deveres de IA obrigam), os Estados Unidos (OMB M-25-21 para agências federais e o NIST AI RMF, voluntário), a cidade de Nova York (Local Law 144 sobre ferramentas automatizadas de contratação), o Colorado (SB26-189, promulgada e em vigor a partir de 1º de janeiro de 2027, portanto não selecionada antes disso), a União Europeia (o AI Act para fornecedores, implantadores, transparência e modelos de uso geral; a maioria dos deveres de alto risco se aplica a partir de 2 de dezembro de 2027, e constatações anteriores descrevem a preparação), o Reino Unido (o Algorithmic Transparency Recording Standard para o governo central e os deveres do UK GDPR que a orientação de IA do ICO explica, com os artigos 22A a 22D sobre decisões automatizadas), Singapura (AI Verify, voluntário) e a ISO/IEC 42001 com os controles de seu Anexo A e a ISO/IEC 23894, voluntárias, apenas por número e título. Um sistema declarado em um Estado-membro da UE, como FR ou DE-BY, é coberto pelos catálogos da UE. Cada catálogo diz nas primeiras linhas que é um rascunho não revisado por um advogado.

Uma evidência, vários catálogos

Uma linha de correspondência oferece uma regra do gate aos requisitos medidos de vários catálogos ao mesmo tempo:

crosswalk:
  - id: fair
    rule: parity-gap
    targets: [DADM-6.3.3#1, EUAIA-10]

Uma linha não vincula nada até que um revisor a aceite para o alvo de um sistema: oloproof governance crosswalk --row fair --system triage --target EUAIA-10 --by "A. Reviewer", registrado no log de revisão. Só esse alvo lê a regra, e só enquanto a linha estiver como foi aceita; uma linha editada é oferecida de novo. --withdraw com as mesmas opções retira uma aceitação. Uma correspondência nunca diz que dois requisitos são o mesmo; diz que a mesma evidência é oferecida a ambos, e a constatação nomeia a linha.

Quando um catálogo deve ser relido

Cada catálogo registra quando foi lido diante do seu instrumento (read_on) e com que frequência deve ser relido (review_every, seis meses por padrão, três para instrumentos em alteração ativa). Passada essa data, suas constatações mantêm seus estados com "catalogue not reread since" ao lado, na página, na exportação e na API. Quando o instrumento foi alterado depois da leitura do catálogo (amended_on), suas constatações ficam como impossíveis de determinar até que ele seja relido.

Por jurisdição, no terminal e no workspace

oloproof governance check encerra sua seleção com um bloco "By jurisdiction": para cada sistema e cada lugar que declarou, os catálogos que o cobrem, a contagem de suas constatações em cada estado e os que estão desatualizados; catálogos que o arquivo nomeia pelo próprio caminho são listados à parte. A página de Governança hospedada mostra o mesmo agrupamento. A exportação de um selo continua sendo apenas o registro assinado; o agrupamento é extraído dele, nunca levado sem assinatura ao seu lado.

O que ela não pode dizer

Um catálogo parafraseia seu instrumento como um leitor o entendeu em um dia. O Oloproof não acompanha mudanças legislativas; a data de revisão e uma pessoa relendo são o mecanismo. Quais instrumentos se aplicam a uma organização, e o que exigem dela, é uma pergunta para um advogado.