Jurisdicciones

Un hallazgo leído por jurisdicción es una ayuda de lectura extraída de catálogos en borrador no revisados por un abogado. Nunca es asesoramiento jurídico ni una afirmación de que un sistema cumple una ley; prevalece el texto oficial de cada instrumento. Declare dónde se usa un sistema, y Oloproof lo lee frente a cada catálogo que cubre ese lugar, nombra cada uno que dejó fuera y por qué, e indica cuándo toca volver a leer un catálogo.

Declarar dónde se usa un sistema

Un sistema en governance.yaml puede declarar jurisdictions:, una lista de códigos ISO 3166: un país (CA, US), una subdivisión (CA-QC, US-CO), una ciudad tras su subdivisión (US-NY-NYC), EU o INT. Añada sector: (public o private) y role: (provider o deployer) donde el alcance de un instrumento dependa de ellos, y nombre el í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 añade entonces a la lista propia del sistema cada catálogo indexado que se aplica e imprime, por sistema, cada catálogo seleccionado o dejado fuera con su motivo: una directiva federal no alcanza a un organismo provincial, se nombra un sector o un rol que no coincide, un marco voluntario se ofrece y nunca se selecciona, y un instrumento propuesto o derogado se cataloga y nunca se selecciona. Un catálogo propuesto nombrado a mano se rechaza en lugar de evaluarse. Un sistema sin jurisdicciones conserva los catálogos que nombra él mismo. Cuando cada sistema declara jurisdicciones, el archivo puede no nombrar ningún catálogo y dejarlos al índice, como arriba; oloproof init --example governance escribe un proyecto así, con los catálogos y su índice copiados en catalogues/.

Un código solo coincide hacia abajo: un catálogo indexado para CA con subdivisiones cubre CA-QC, pero un sistema que declara US-NY no queda cubierto por un catálogo para US-NY-NYC. Declare el lugar más preciso donde se usa el sistema, y cada lugar donde se usa.

Qué contiene el índice

Cada entrada de catalogues.yaml nombra un archivo de catálogo, las jurisdicciones que cubre, si cubre sus subdivisiones y dónde se aplica: sector, role, voluntary y status (in_force, proposed o repealed), con una note opcional que dice por qué no se selecciona un instrumento propuesto. Indexa Canadá (la directiva federal y su evaluación de impacto algorítmico, la Policy on Service and Digital y su guía, el proyecto de ley C-36, propuesto), Quebec (sus leyes de privacidad de los sectores privado y público), Ontario (su directiva de IA y la Enhancing Digital Security and Trust Act, propuesta hasta que un reglamento nombre a quién obligan sus deberes de IA), Estados Unidos (OMB M-25-21 para las agencias federales y el NIST AI RMF, voluntario), la ciudad de Nueva York (Local Law 144 sobre herramientas de contratación automatizadas), Colorado (SB26-189, promulgada y vigente desde el 1 de enero de 2027, por lo que no se selecciona antes), la Unión Europea (la Ley de IA para proveedores, responsables del despliegue, transparencia y modelos de uso general; la mayoría de los deberes de alto riesgo se aplican desde el 2 de diciembre de 2027, y los hallazgos anteriores describen la preparación), el Reino Unido (el Algorithmic Transparency Recording Standard para el gobierno central y los deberes del UK GDPR que explica la guía de IA de la ICO, con los artículos 22A a 22D sobre decisiones automatizadas), Singapur (AI Verify, voluntario) e ISO/IEC 42001 con los controles de su anexo A e ISO/IEC 23894, voluntarias, solo por número y título. Un sistema declarado en un Estado miembro de la UE, como FR o DE-BY, queda cubierto por los catálogos de la UE. Cada catálogo dice en sus primeras líneas que es un borrador no revisado por un abogado.

Una evidencia, varios catálogos

Una fila de correspondencia ofrece una regla del gate a los requisitos medidos de varios catálogos a la vez:

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

Una fila no vincula nada hasta que un revisor la acepta para el objetivo de un sistema: oloproof governance crosswalk --row fair --system triage --target EUAIA-10 --by "A. Reviewer", registrado en el registro de revisión. Solo ese objetivo lee la regla, y solo mientras la fila siga como se aceptó; una fila editada se ofrece de nuevo. --withdraw con las mismas opciones retira una aceptación. Una correspondencia nunca dice que dos requisitos son el mismo; dice que se ofrece la misma evidencia a ambos, y el hallazgo nombra la fila.

Cuándo toca volver a leer un catálogo

Cada catálogo registra cuándo se leyó frente a su instrumento (read_on) y cada cuánto toca de nuevo (review_every, seis meses por defecto, tres para instrumentos en reforma activa). Pasada esa fecha, sus hallazgos conservan su estado con «catalogue not reread since» al lado, en la página, en la exportación y en la API. Cuando el instrumento se modificó después de leer el catálogo (amended_on), sus hallazgos se leen como imposibles de determinar hasta que se vuelva a leer.

Por jurisdicción, en la terminal y en el espacio de trabajo

oloproof governance check cierra su selección con un bloque «By jurisdiction»: para cada sistema y cada lugar que declaró, los catálogos que lo cubren, el número de sus hallazgos en cada estado y los que están desactualizados; los catálogos que el archivo nombra con su propia ruta se listan aparte. La página de Gobernanza alojada muestra la misma agrupación. La exportación de un sellado sigue siendo solo el registro firmado; la agrupación se obtiene de él y nunca se lleva sin firmar a su lado.

Lo que no puede decirle

Un catálogo parafrasea su instrumento tal como un lector lo entendió un día. Oloproof no sigue los cambios legislativos; la fecha de revisión y una persona que vuelve a leer son el mecanismo. Qué instrumentos se aplican a una organización, y qué le exigen, es una pregunta para un abogado.