Conformità del recruiting basato su IA attraverso sei regimi

Una singola esecuzione dell'audit, sei deliverable modellati per giurisdizione e un punto in cui due regimi non possono essere entrambi soddisfatti.

Clarion è un overlay di conformità che si integra con gli strumenti di assunzione basati su IA già utilizzati da un datore di lavoro. Legge un unico export di punteggio del fornitore, calcola ogni statistica sull'impatto negativo in codice deterministico e declina quel singolo audit in sei deliverable modellati per NYC, Colorado, Illinois, Texas, California e UE. Dove due di questi regimi richiedono requisiti opposti per la medesima caratteristica, lo evidenzia e quantifica entrambe le esposizioni anziché mostrare «pienamente conforme». Quanto segue è una demo su un export sintetico preconfigurato, non una pipeline distribuita.

6

Deliverable di giurisdizione da una singola esecuzione dell'audit

NYC, Colorado, Illinois, Texas, California, UE

9 su 13

Obblighi instradati a un responsabile umano designato, non approvati automaticamente

7 NEEDS PROOF più 2 CONFLICT, sull'export preconfigurato della demo

1

Conflitto che il gate rifiuta di eludere

Illinois HB 3773 contro EU AI Act Article 10(3)

Il dataset è sintetico: un export preconfigurato di «Acme Logistics, Inc.» di 1,040 candidati sulla posizione REQ-2026-0412, valutati da tre strumenti simulati. Gli strumenti di scoring in stile Workday-Spotlight, stile HireVue e stile Eightfold sono archetipi gestiti da adapter fixture fittizi (stub), non integrazioni, e nessun datore di lavoro o candidato reale compare in esso.

Sei regolatori hanno esaminato lo stesso stack di assunzione e hanno posto sei domande strutturalmente diverse.

Un CHRO, General Counsel o Chief Risk Officer che gestisce strumenti di assunzione automatizzati in due o più giurisdizioni tra NYC, Colorado, Illinois, Texas, California e UE risponde a sei regimi distinti con un unico stack. I fornitori di tale stack rilasciano un unico audit del tipo «abbiamo superato la regola dei quattro quinti» come se risolvesse tutti e sei. Non è così. La NYC Local Law 144 richiede rapporti di impatto intersezionali. La legge Colorado SB 24-205 richiede un programma documentato di ragionevole diligenza e non specifica alcuna metodologia. La legge Texas TRAIGA respinge l'impatto disparato come base autonoma e indaga sull'intenzionalità, rendendo le statistiche che guidano il deliverable di NYC del tutto irrilevanti a fini probatori per quello del Texas. L'EU AI Act richiede che i dati di addestramento siano rappresentativi e fa affidamento proprio sulla caratteristica geografica che l'Illinois vieta come proxy.

La maggior parte degli audit non è affatto presente

I ricercatori che hanno cercato gli audit sui bias pubblicati ai sensi della Local Law 144 li hanno trovati per il 4.6% di 391 datori di lavoro di NYC, una constatazione definita Null Compliance (Cornell / Data & Society / Consumer Reports, FAccT 2024). La pubblicazione dell'audit rappresenta la metà visibile dell'obbligo, e la maggior parte del campione non l'aveva raggiunta.

L'attività di applicazione si sta intensificando

Il NY State Comptroller ha riscontrato 17 potenziali violazioni della Local Law 144 nello stesso campione di 32 aziende in cui il DCWP ne aveva trovata una sola, e il DCWP ha concordato di passare a un'applicazione proattiva (NY State Comptroller, December 2, 2025). Il divario tra un audit superato del fornitore e una documentazione difendibile è proprio il punto su cui si concentra tale applicazione.

Un audit sui bias non esaurisce l'intera esposizione

L'autoclassificazione dell'ambito, l'accessibilità ADA nei colloqui video e gli obblighi di azione avversa ai sensi del FCRA sono teorie giuridiche distinte che un audit sui bias superato non ha mai verificato. Mobley v. Workday, D.K. v. Intuit/HireVue e Kistler v. Eightfold ne sollevano ciascuno una, e nessuna è stata decisa.

I numeri e i verdetti sono stabiliti in codice deterministico, e il team di agenti che li narra non può accedere a nessuno dei due.

La pipeline è breve e la divisione del lavoro al suo interno è rigorosa. Un export AEDT del fornitore viene normalizzato in un unico schema di record canonico, un motore deterministico calcola ogni statistica, sei pacchetti di regole di regime e un policy gate decidono ogni obbligo, un team di agenti redige il testo e l'esecuzione sigilla un pacchetto pre-audit concatenato tramite hash. Gli agenti consigliano, il codice decide: è questo che rende l'output depositabile a livello normativo, a prescindere dalla qualità del modello sottostante.

01 / IL NUCLEO DI FIDUCIA DETERMINISTICO

Ogni statistica calcolata all'esterno del framework di agenti

Un motore numpy calcola i rapporti di impatto marginali dei quattro quinti, i rapporti intersezionali razza per sesso con controllo FDR di Benjamini-Hochberg, il rilevamento di proxy di classi protette mediante Cramér's V, un'inversione controfattuale dell'attributo protetto tramite un surrogato trasparente di regressione logistica, la disparità del tasso di errore sulle parole ASR sul sottoinsieme video e un predicato di attivazione FCRA. Stesso input, stesso output, a ogni esecuzione.

02 / SEI PACCHETTI DI REGOLE E IL POLICY GATE

Quattro verdetti, decisi in codice puro

Ciascun regime include la propria citazione, la data di entrata in vigore e il formato del deliverable richiesto, e ciascun obbligo si risolve in PASS, FAIL, NEEDS PROOF o CONFLICT. Il gate è l'unico elemento non accessibile al modello linguistico, pertanto una narrazione ben argomentata non potrà mai spostare un obbligo da NEEDS PROOF a verde.

03 / IL TEAM DI AGENTI

Sei narratori, un conciliatore e uno scettico

Sei agenti di giurisdizione narrano il verdetto di ciascun regime, un conciliatore di conflitti trasforma un conflitto bloccante in un memo di strategia legale con l'esposizione di ogni opzione, e uno scettico contraddittorio tenta di confutare ogni superamento dichiarato instradando ciò che non può validare alla verifica umana. Il team consente l'interscambio dei fornitori; senza alcun fornitore configurato, ricorre a template deterministici e l'applicazione funziona in modo identico.

04 / IL PACCHETTO PRE-AUDIT

Un pacchetto creato per essere sottoscritto da un terzo

L'esecuzione sigilla un bundle concatenato tramite hash SHA-256 di 17 nodi, ciascuno recante i propri input, il proprio calcolo e la citazione della regola più un link all'hash del nodo precedente, cosicché qualsiasi modifica interrompe la catena. Viene esportato come JSON e come fascicolo per l'auditor in HTML stampabile, e la catena viene verificata a ogni esecuzione e sottoposta a unit test contro le manomissioni.

La console è articolata su due viste più finestre di dialogo interattive anziché un unico cruscotto. Manual Testing ospita la barra delle fasi, la traccia live di Audit Execution e la scheda dei candidati. Run Benchmark, che rimane disabilitato fino al completamento di Run Audit, passa a Benchmark Results: tre riquadri con Jurisdiction Deliverables 6, Lowest Impact Ratio 0.65 e Items Requiring Human Action 9, le sei righe di Jurisdiction Deliverables, una riga di pulsanti Supporting Evidence ed Export Pre-Audit Package nell'intestazione.

Tutti gli elementi sottostanti si aprono come finestre di dialogo. Selection-Rate Analysis, Conflict Register e Human Proof Queue sono i tre pulsanti di Supporting Evidence, e gli obblighi e la narrazione di audit di ciascun regime si aprono dalla rispettiva riga di deliverable. Nulla viene sintetizzato in un unico punteggio, poiché un unico punteggio non può essere fedele rispetto a sei domande formulate in modo strutturalmente diverso.

L'audit del fornitore è superato. L'audit effettivamente richiesto dalla legge fallisce, sugli stessi dati.

La demo effettua l'audit di un export sintetico preconfigurato di 1,040 candidati sulla posizione REQ-2026-0412, valutati da tre strumenti di fornitori simulati. La violazione al suo interno è inserita intenzionalmente e riproducibile, concepita affinché il motore abbia un elemento reale da rilevare. Ecco cosa compare a schermo durante l'esecuzione, nell'ordine in cui viene presentato.

La console Clarion con la finestra di dialogo Dataset Preview aperta sopra la barra dell'applicazione, che elenca 16 record rappresentativi di quella che la finestra di dialogo definisce la popolazione di audit deterministica di 1,040 candidati, la quale è preconfigurata e sintetica. Ogni scheda mostra un nome, un ruolo come Operations Analyst o Warehouse Associate, tag di coorte di razza e sesso, un punteggio del fornitore e una decisione verde Advanced o rossa Screened Out. I controlli nell'intestazione indicano About Demo, View Dataset, Run Audit e un pulsante disattivato in grigio Run Benchmark.
Cosa compare prima dell'esecuzione di qualsiasi audit. View Dataset apre 16 record sintetici rappresentativi, ciascuno corrispondente a una decisione già presa da uno strumento fornitore: un punteggio e un'ammissione o un rifiuto. Qui non compare alcun rapporto di impatto, poiché l'applicazione non mostra alcun auto-audit del fornitore prima dell'esecuzione. L'intero audit opera a partire da questo singolo export normalizzato, e Clarion non attribuisce mai punteggi né stila graduatorie di candidati in modo autonomo.
La vista Benchmark Results di Clarion. Tre riquadri indicano Jurisdiction Deliverables 6, Lowest Impact Ratio 0.65 e Items Requiring Human Action 9. Sotto una traccia di Benchmark Execution in sei passaggi, sei righe di Jurisdiction Deliverables riportano NYC Local Law 144 Live FAIL con 3 obblighi, Colorado AI Act SB 24-205 effective Jun 30 2026 NEEDS PROOF con 2, Illinois HB 3773 Live CONFLICT con 2, Texas TRAIGA Live NEEDS PROOF con 2, California FEHA ADS amendments Live FAIL con 2, ed EU AI Act Annex III effective Aug 2 2026 CONFLICT con 2. Una riga Supporting Evidence sottostante propone Selection-Rate Analysis, Conflict Register e Human Proof Queue.
Un solo audit, sei formati, nessuna sequenza di conferme verdi. Ciascuna riga include la propria citazione, la data di entrata in vigore e il formato del deliverable: un report di impatto negativo intersezionale per NYC, una valutazione di impatto di ragionevole diligenza per il Colorado, elementi di notifica e correzione dei proxy per l'Illinois, una valutazione basata sull'intenzionalità per il Texas, un fascicolo di registri con attestazione di conservazione quadriennale per la California, e un fascicolo Article 10 e Article 11 per l'UE. Tra questi sei deliverable sono distribuiti 13 obblighi: 2 PASS, 2 FAIL, 7 NEEDS PROOF e 2 CONFLICT.
La finestra di dialogo Selection-Rate Analysis di Clarion. Una scheda dei tassi di impatto negativo elenca White con un tasso di ammissione del 51% e un rapporto di impatto di 1.00, Asian al 49% e 0.95, Hispanic al 42% e 0.82, e Black al 42% e 0.82, con una riga che indica che sia il rapporto marginale di razza 0.8196 sia il rapporto di sesso 0.8744 superano la soglia dei quattro quinti di 0.80, punto in cui il fornitore si ferma. Un timbro rosso FOUR-FIFTHS FAIL accanto spiega che segmentando gli stessi dati per razza e sesso la coorte Black / Female si colloca a 0.65 rispetto a White Male. La griglia Race × Sex Selection Grid (LL144) sottostante mostra White Male 1.00, White Female 0.96, Asian Male 0.96, Asian Female 0.91, Hispanic Male 0.84, Hispanic Female 0.76 in ambra, Black Male 0.96 e Black Female 0.65 in rosso con il 34% di selezionati.
Il punto di svolta. Il test marginale dei quattro quinti viene effettivamente superato a 0.8196 per la razza e a 0.8744 per il sesso. Questo è l'audit rilasciato dall'auto-report del fornitore, ed è realmente superato. Segmentando le stesse righe per razza e sesso, come richiesto dalla Local Law 144, la cella Black / Female ammette 44 candidati su 130 con un rapporto di impatto di 0.6471 rispetto alla cella di riferimento White / Male. Sotto controllo FDR di Benjamini-Hochberg con alpha 0.05, solo quella cella risulta statisticamente robusta a q = 0.0185; Hispanic / Female a 0.7647 viene segnalata ma non definita significativa, a q = 0.1629. La disparità è inserita intenzionalmente e sintetica, e la capacità del motore di distinguere un risultato robusto da uno casuale è ciò che un audit esclusivamente marginale non ha alcun modo di produrre.
La finestra di dialogo NYC Local Law 144 di Clarion, contrassegnata come FAIL e Live, per il deliverable del report sull'impatto negativo intersezionale LL144 con sintesi pubblica pubblicata. Il suo Obligation Review elenca i rapporti di impatto marginali dei quattro quinti come PASS con minimo per la razza di 0.8196 e minimo per il sesso di 0.8744, i rapporti di impatto intersezionali razza per sesso come FAIL con un rapporto di impatto Black / Female di 0.6471 e celle non conformi Hispanic / Female e Black / Female, e una voce NEEDS PROOF sull'autoclassificazione dell'ambito che richiede un'attestazione di un consulente legale umano. Una narrazione di audit sottostante spiega l'aggregazione complessiva.
Ciascun verdetto si articola nei rispettivi obblighi. La riga di NYC è un unico deliverable che racchiude tre obblighi con tre stati distinti: i rapporti marginali ottengono PASS a 0.8196 e 0.8744, i rapporti intersezionali ottengono FAIL a 0.6471 e la questione dell'ambito resta su NEEDS PROOF fino a quando un responsabile umano designato non fornisce una risposta. La riga mantiene tutti e tre gli stati affiancati anziché fonderli in uno solo, di modo che un PASS nel test marginale non sostituisca mai il test intersezionale che la LL144 effettivamente prescrive.
La finestra di dialogo Conflict Register di Clarion che segnala CONFLICT su zip_code e dati geografici tra il_hb3773 ed eu_ai_act. Il testo spiega che l'Illinois HB 3773 vieta i codici di avviamento postale come proxy di classi protette, cosicché la configurazione conforme per l'Illinois maschera i dati geografici, mentre l'EU AI Act Article 10(3) richiede dati di addestramento pertinenti, rappresentativi e completi, il che presuppone solitamente una copertura geografica, e che la rimozione del codice postale compromette la rappresentatività per l'UE mentre mantenerlo viola la legge dell'Illinois. Una raccomandazione suggerisce due configurazioni di un medesimo modello, o l'accettazione consapevole di un'esposizione documentandola debitamente, precisando che il sistema non certificherà la piena conformità.
Il conflitto che non si può eludere. Il motore ha misurato zip_region, che il Conflict Register etichetta come zip_code / geographic data, rispetto alla razza con un Cramér's V di 0.3321, al di sopra della soglia di 0.2, e ha validato school_tier a 0.0711 nel medesimo passaggio, dimostrando così di non segnalare indiscriminatamente qualsiasi variabile. L'Illinois vieta il proxy; la rappresentatività dell'UE richiede quella medesima copertura geografica. Poiché un'unica configurazione del modello non può soddisfare entrambi i requisiti, il gate genera CONFLICT e il conciliatore redige invece il memo di strategia: due configurazioni di distribuzione, o un'esposizione accettata consapevolmente e documentata, con le sanzioni per l'alto rischio dell'UE indicate al rispettivo massimo legale pari al valore più elevato tra 15 million euros o il 3% del fatturato annuo globale.
La finestra di dialogo Human Proof Queue di Clarion che elenca tre contestazioni dello scettico. L'ambito AEDT per tutti gli strumenti di scoring e filtraggio, a fronte di un memo del fornitore in cui si dichiara che lo strumento non è un AEDT, a cui si replica che l'autoclassificazione non costituisce una difesa valida e instradato a un'attestazione dell'ambito da parte di un consulente legale umano. Una pipeline ASR di colloqui video in stile HireVue, a fronte della tesi secondo cui un audit sui bias di razza e sesso superato sia sufficiente a coprirla, a cui si replica che un audit sui bias di razza e sesso non equivale a una difesa sull'accessibilità e instradata a una revisione umana dell'accessibilità ADA e ASR corredata da un flusso di accomodamento ragionevole. Un flusso di valutazione basato su dati di terze parti in stile Eightfold, a fronte della pretesa di assenza di ulteriore esposizione, a cui si replica che l'equità del punteggio è irrilevante ai sensi del FCRA e instradata all'infrastruttura di notifica di azione avversa e contestazione del FCRA.
Tre rifiuti, ciascuno instradato a un responsabile umano designato. Sui 432 candidati della sessione video nell'export sintetico preconfigurato, il tasso di errore sulle parole è di 0.0794 per il linguaggio standard contro 0.3016 per i 104 candidati con linguaggio non standard, una disparità di 3.8 volte che la Local Law 144 non verifica mai. Separatamente, 510 candidati sono stati valutati a partire da dati estratti da terze parti e filtrati in base a un punteggio numerico, il che attiva il presupposto del FCRA: se la piattaforma agisce come agenzia di informazioni creditizie o commerciali (consumer reporting agency), a ogni candidato valutato è dovuta una notifica di azione avversa e una via di contestazione a prescindere da quanto sia equo il punteggio. Clarion rileva e instrada entrambi i casi. Il flusso di accomodamento e il portale di contestazione rivolto ai candidati indicati in tali percorsi restano in capo al datore di lavoro e non sono qualcosa che sviluppiamo qui; queste tre contestazioni costituiscono un oggetto distinto rispetto ai 9 obblighi conteggiati come NEEDS PROOF o CONFLICT.
Il pacchetto pre-audit Clarion esportato per Acme Logistics, Inc., che elenca le giurisdizioni NYC, Illinois ed EU su 1040 candidati. La sua riga di integrità recita SHA-256 hash chain, 17 nodes, con un hash di testa e una spunta verde VERIFIED. Una riga di copertura riporta 15% of 13 obligations auto-satisfied e 69% routed to human proof, con 2 fail, 7 needs-proof e 2 conflict, e un audit che genera 6 deliverable di giurisdizione. Una nota specifica che Veriprajna produce questo pacchetto pre-audit e che la validazione formale indipendente LL144 resta di competenza di DCI Consulting, ORCAA o Secretariat. Seguono sotto le tabelle dei verdetti per regime.
La ricevuta. Export Pre-Audit Package genera il bundle come JSON e come questo fascicolo per l'auditor stampabile: 17 nodi concatenati tramite hash con la catena verificata all'esecuzione, ogni numero corredato dal relativo calcolo e ogni verdetto dalla relativa citazione. La riga di copertura riporta 15% e 69%, corrispondenti ai 2 obblighi soddisfatti automaticamente su 13 e ai 9 contrassegnati come NEEDS PROOF o CONFLICT su 13; i 2 obblighi FAIL non rientrano in nessuna delle due cifre. Il pacchetto specifica nella propria intestazione che la validazione formale indipendente non compete a noi.

Cosa afferma questa demo, e cosa deliberatamente non afferma.

Ogni dato presente in questa pagina descrive un unico export sintetico preconfigurato di 1,040 candidati con una violazione inserita intenzionalmente e riproducibile. Tali dati dimostrano che il motore rileva ciò che un audit esclusivamente marginale tralascia. Non rappresentano un tasso di accuratezza, non costituiscono un benchmark rispetto ad altri prodotti e non costituiscono un'affermazione sui dati di assunzione di alcun datore di lavoro reale.

DomandaCosa fa Clarion in questa demoCosa rimane al di fuori della demo
CoperturaUna singola esecuzione dell'audit genera sei deliverable modellati per giurisdizione su 13 obblighi, con 2 PASS, 2 FAIL, 7 NEEDS PROOF e 2 CONFLICT.Un certificato di conformità o un punteggio di equità. Il gate è progettato appositamente per rifiutarne il rilascio.
Impatto negativoRapporti dei quattro quinti marginali e intersezionali con controllo FDR di Benjamini-Hochberg, rilevamento di proxy mediante Cramér's V e un'inversione controfattuale che varia la probabilità di avanzamento di 0.0574 in media e di 0.1228 al massimo.Qualsiasi dichiarazione sugli esiti reali delle assunzioni. I 1,040 candidati, la posizione e la disparità sono sintetici e preconfigurati.
Dati dei fornitoriLegge un unico export AEDT normalizzato generato da strumenti di scoring in stile Workday-Spotlight, stile HireVue e stile Eightfold, gestiti da adapter fixture fittizi (stub).Connettori live verso qualsiasi ATS, piattaforma di valutazione o motore di matching. Nessun fornitore menzionato è cliente, partner o sostenitore.
Azione a valleRileva e instrada l'esito sull'accessibilità ADA e ASR e l'attivazione di azione avversa FCRA a un responsabile umano designato, con le prove allegate.Il flusso di accomodamento CART e il portale di contestazione rivolto ai candidati. Entrambi sono simulati nella demo e non costituiscono qualcosa che sviluppiamo qui.
Validazione formaleSigilla un pacchetto pre-audit di 17 nodi concatenati tramite hash, verificato all'esecuzione e sottoposto a unit test contro le manomissioni, in JSON e HTML stampabile.L'audit indipendente sui bias vero e proprio. Società come DCI Consulting, ORCAA e Secretariat svolgono tale ruolo, e noi non lo facciamo.

Cosa questa demo NON fa

Clarion non certifica la conformità, e rifiutarsi di farlo è parte integrante del suo design. Non è un modello di assunzione e non attribuisce mai punteggi né stila graduatorie di candidati. Il dataset è sintetico e preconfigurato, la disparità Black / Female al suo interno è inserita intenzionalmente affinché il motore disponga di un elemento reale da rilevare anziché essere un riscontro su un datore di lavoro effettivo, e i connettori dei fornitori sottostanti sono adapter fixture fittizi (stub) anziché integrazioni live. Lo strumento produce elementi di prova per i consulenti legali: non fornisce consulenza legale né esprime pareri sulle responsabilità, e Mobley v. Workday, D.K. v. Intuit/HireVue e Kistler v. Eightfold sono teorie pendenti anziché esiti decisi. I massimi legali sono citati unicamente come massimi, e qui non compare alcuna cifra di esposizione modellata. Questa pagina è una guida esplicativa con video dimostrativo, screenshot reali, funzionamento del meccanismo e risposte, non un'applicazione da azionare direttamente da qui.

Cosa chiede un General Counsel prima di inserire un livello di conformità sopra lo stack di assunzione.

Il nostro fornitore ha già eseguito un audit sui bias ed è stato superato. Perché dovremmo averne bisogno di un secondo?

Perché il test che viene superato e il test richiesto dalla legge non sono lo stesso test. Sull'export sintetico preconfigurato di 1,040 candidati della demo, la verifica marginale dei quattro quinti viene superata, con un rapporto di impatto minimo per la razza di 0.8196 e un rapporto minimo per il sesso di 0.8744 rispetto alla soglia di 0.80, e questo è l'audit che l'auto-report del fornitore fornisce. La NYC Local Law 144 richiede i rapporti intersezionali razza per sesso, e lì la cella Black / Female ammette 44 candidati su 130 con un rapporto di impatto di 0.6471. Un audit esclusivamente marginale non commette un errore su tale cella: ne è strutturalmente cieco.

Siete voi l'auditor? Potete sottoscrivere e convalidare il nostro audit della Local Law 144?

No. Veriprajna non è l'auditor indipendente, e quel ruolo spetta a società come DCI Consulting, ORCAA o Secretariat. Clarion produce il pacchetto pre-audit, un fascicolo concatenato tramite hash in cui ogni numero reca il rispettivo calcolo e ogni verdetto la rispettiva citazione, strutturato affinché un auditor indipendente possa sottoscriverlo senza doverlo riscrivere. L'obiettivo è portare il sistema nello stato in cui l'audit non rilevi nulla che valga la pena segnalare.

Questo si collega a Workday o HireVue? Non intendiamo sostituire il nostro stack di assunzione.

Non si collega a nessuno dei due, e Clarion non assegna mai punteggi né posiziona in graduatoria alcun candidato. Nulla nel vostro stack viene sostituito. Legge un export AEDT del fornitore e lo normalizza in un unico schema di record canonico. In questa demo i connettori dei fornitori sono adapter fixture fittizi (stub) su dati sintetici, e il sistema di scoring in stile Workday-Spotlight, la sessione video in stile HireVue e il motore di matching in stile Eightfold sono archetipi anziché integrazioni.

C'è un LLM all'interno. Come posso presentarlo a un regolatore?

Ogni statistica, ogni confronto di soglia, ogni connessione di conflitto e l'hashing del bundle risiedono in codice deterministico all'esterno del framework di agenti. I sei agenti di giurisdizione, il conciliatore di conflitti e lo scettico contraddittorio redigono il testo; non calcolano mai alcun numero e non possono ignorare il policy gate. Senza alcun provider di modelli configurato, il team ricorre a template deterministici e l'applicazione genera i medesimi verdetti, poiché i verdetti non sono mai stati di competenza del modello.

Cosa succede quando due regimi richiedono elementi opposti? Abbiamo bisogno di una decisione, non di un'alzata di spalle.

Si ottiene il bilanciamento quantificato e verbalizzato per iscritto. Nella demo la caratteristica zip_region si correla con la razza con un Cramér's V di 0.3321, al di sopra della soglia di 0.2, pertanto l'Illinois HB 3773 la considera un proxy vietato mentre la rappresentatività ai sensi dell'EU AI Act Article 10(3) fa leva sulla medesima copertura geografica. Il gate genera CONFLICT anziché un'approvazione, e il conciliatore redige un memo di strategia: eseguire due configurazioni di distribuzione, o accettare consapevolmente un'esposizione documentandola, tenendo presente che le sanzioni per l'alto rischio dell'UE raggiungono il massimo legale pari al valore più elevato tra 15 million euros o il 3% del fatturato annuo globale.

Nove obblighi su tredici richiedono l'intervento umano. Questo ci fa davvero risparmiare qualcosa?

Automatizza la parte che è onesto automatizzare. Sull'export sintetico della demo 2 obblighi su 13 sono soddisfatti automaticamente, 2 falliscono nettamente e 9 vengono instradati come NEEDS PROOF o CONFLICT a un responsabile umano designato con le prove già raccolte e la citazione allegata. Nessun sistema onesto approva tutti e tredici su questi dati. Una dashboard che mostrasse tredici conferme verdi li starebbe approvando senza prove, e tale dashboard sarebbe la prova documentale che una parte attrice vi contesterebbe. Il motore convalida inoltre school_tier come non proxy con un Cramér's V di 0.0711, a dimostrazione del fatto che non segnala indiscriminatamente tutto ciò che analizza.

Cosa consegniamo effettivamente all'auditor alla fine?

Un unico export genera un pacchetto pre-audit come JSON e come fascicolo per l'auditor in HTML stampabile, versione 1 del formato veriprajna-pre-audit-package, recante 17 nodi con la catena verificata all'esecuzione. Ciascun nodo racchiude i propri input, il proprio calcolo e la citazione della regola più un collegamento SHA-256 al nodo precedente, cosicché qualsiasi modifica a un nodo interrompe la catena. Al suo fianco si collocano i sei deliverable di giurisdizione, ciascuno modellato sulla citazione, sulla data di entrata in vigore e sul formato richiesto dal rispettivo regime.

Technical Research

La ricerca alla base di questa demo: l'architettura, il modello di verifica e il blueprint aziendale.

Social

Pubblicato anche su

Inizia dai due regimi che il tuo stack di assunzione potrebbe non essere in grado di soddisfare contemporaneamente.

Siamo un team di ingegneria dell'IA, non un ente di certificazione della conformità. Creiamo il livello deterministico che calcola le statistiche, modella il deliverable richiesto da ciascun regolatore ed esplicita chiaramente le contraddizioni affinché i consulenti legali possano decidere con piena visibilità sui rischi.

Un primo confronto utile è concreto: quali fornitori di AEDT sono presenti nel vostro funnel, a quali dei sei regimi siete effettivamente esposti e quali caratteristiche in tali modelli apparirebbero come proxy di classi protette ai sensi di uno di essi. Possiamo analizzare il motore, i pacchetti di regole e il formato del pacchetto pre-audit insieme ai vostri team HR, legali e data.

Valutazione dell'esposizione agli AEDT

  • ✓ Strumenti di fornitori che valutano o filtrano i candidati
  • ✓ Quali dei sei regimi interessano il vostro funnel
  • ✓ Caratteristiche che agiscono come proxy di classi protette
  • ✓ Teorie di ambito, ADA e FCRA che un audit sui bias tralascia

Costruire l'overlay di conformità

  • ✓ Motore deterministico di impatto negativo
  • ✓ Pacchetti di regole per regime e policy gate
  • ✓ Conciliazione dei conflitti e instradamento alla verifica umana
  • ✓ Formato del pacchetto pre-audit concatenato tramite hash