Giurisdizioni

Un rilievo letto per giurisdizione è un aiuto alla lettura tratto da cataloghi in bozza non esaminati da un legale. Non è mai una consulenza legale né un'affermazione che un sistema rispetta una legge; fa fede il testo ufficiale di ciascuno strumento. Dichiarate dove è usato un sistema, e Oloproof lo legge rispetto a ogni catalogo che copre quel luogo, nomina ciascuno di quelli esclusi e il perché, e dice quando un catalogo va riletto.

Dichiarare dove è usato un sistema

Un sistema in governance.yaml può dichiarare jurisdictions:, un elenco di codici ISO 3166: un paese (CA, US), una suddivisione (CA-QC, US-CO), una città dopo la sua suddivisione (US-NY-NYC), EU o INT. Aggiungete sector: (public o private) e role: (provider o deployer) dove la portata di uno strumento ne dipende, e nominate l'indice dei cataloghi:

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 aggiunge allora all'elenco proprio del sistema ogni catalogo indicizzato che si applica e stampa, per sistema, ogni catalogo selezionato o escluso con il suo motivo: una direttiva federale non raggiunge un ente provinciale, un settore o un ruolo che non corrisponde viene nominato, un quadro volontario viene offerto e mai selezionato, e uno strumento proposto o abrogato viene catalogato e mai selezionato. Un catalogo proposto nominato a mano viene rifiutato anziché valutato. Un sistema senza giurisdizioni mantiene i cataloghi che nomina da sé. Quando ogni sistema dichiara giurisdizioni, il file può non nominare alcun catalogo e lasciarli all'indice, come sopra; oloproof init --example governance scrive un progetto così, con i cataloghi e il loro indice copiati in catalogues/.

Un codice corrisponde solo verso il basso: un catalogo indicizzato per CA con le suddivisioni copre CA-QC, ma un sistema che dichiara US-NY non è coperto da un catalogo per US-NY-NYC. Dichiarate il luogo più preciso in cui il sistema è usato, e ogni luogo in cui è usato.

Cosa contiene l'indice

Ogni voce di catalogues.yaml nomina un file di catalogo, le giurisdizioni che copre, se copre le loro suddivisioni, e dove si applica: sector, role, voluntary e status (in_force, proposed o repealed), con una note facoltativa che dice perché uno strumento proposto non è selezionato. Indicizza il Canada (la direttiva federale e la sua valutazione d'impatto algoritmico, la Policy on Service and Digital e le sue linee guida, il disegno di legge C-36, proposto), il Québec (le sue leggi sulla privacy del settore privato e pubblico), l'Ontario (la sua direttiva sull'IA e l'Enhancing Digital Security and Trust Act, proposto finché un regolamento non nomina chi vincolano i suoi obblighi sull'IA), gli Stati Uniti (OMB M-25-21 per le agenzie federali e il NIST AI RMF, volontario), New York City (la Local Law 144 sugli strumenti di assunzione automatizzati), il Colorado (SB26-189, approvata e in vigore dal 1° gennaio 2027, quindi non selezionata prima), l'Unione europea (l'AI Act per fornitori, deployer, trasparenza e modelli per finalità generali; la maggior parte degli obblighi ad alto rischio si applica dal 2 dicembre 2027, e i rilievi precedenti descrivono la preparazione), il Regno Unito (l'Algorithmic Transparency Recording Standard per il governo centrale e gli obblighi dello UK GDPR che la guida dell'ICO sull'IA spiega, con gli articoli da 22A a 22D sulle decisioni automatizzate), Singapore (AI Verify, volontario) e ISO/IEC 42001 con i controlli del suo allegato A e ISO/IEC 23894, volontarie, solo per numero e titolo. Un sistema dichiarato in uno Stato membro dell'UE, come FR o DE-BY, è coperto dai cataloghi dell'UE. Ogni catalogo dice nelle prime righe che è una bozza non esaminata da un legale.

Una prova, più cataloghi

Una riga di corrispondenza offre una regola del gate ai requisiti misurati di più cataloghi insieme:

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

Una riga non vincola nulla finché un revisore non la accetta per l'obiettivo di un sistema: oloproof governance crosswalk --row fair --system triage --target EUAIA-10 --by "A. Reviewer", registrato nel registro di revisione. Solo quell'obiettivo legge la regola, e solo finché la riga resta com'era quando è stata accettata; una riga modificata viene offerta di nuovo. --withdraw con le stesse opzioni ritira un'accettazione. Una corrispondenza non dice mai che due requisiti sono lo stesso; dice che la stessa prova è offerta a entrambi, e il rilievo nomina la riga.

Quando un catalogo va riletto

Ogni catalogo registra quando è stato letto rispetto al suo strumento (read_on) e ogni quanto va riletto (review_every, sei mesi per impostazione predefinita, tre per gli strumenti in corso di modifica). Oltre quella data i suoi rilievi mantengono il loro stato con «catalogue not reread since» accanto, nella pagina, nell'esportazione e nell'API. Quando lo strumento è stato modificato dopo la lettura del catalogo (amended_on), i suoi rilievi risultano non determinabili finché non viene riletto.

Per giurisdizione, nel terminale e nel workspace

oloproof governance check chiude la sua selezione con un blocco «By jurisdiction»: per ogni sistema e ogni luogo dichiarato, i cataloghi che lo coprono, il numero dei loro rilievi in ciascuno stato e quelli scaduti; i cataloghi che il file nomina con un proprio percorso sono elencati a parte. La pagina Governance ospitata mostra lo stesso raggruppamento. L'esportazione di un sigillo resta il solo record firmato; il raggruppamento ne è tratto, mai portato non firmato accanto a esso.

Cosa non può dirvi

Un catalogo parafrasa il suo strumento come un lettore lo ha capito in un certo giorno. Oloproof non segue i cambiamenti legislativi; la data di revisione e una persona che rilegge sono il meccanismo. Quali strumenti si applicano a un'organizzazione, e cosa le richiedono, è una domanda per un legale.