Talent Board governed

人材データベース — HR SaaS (kaonavi 等) の OSS 置き換え。人材データを SaaS に人質に取られず、HR-LLM の全操作を独立 PolicyGovernor が検閲する。 cloud-itonami-isic-6310 のライブデモ(合成データ)。

カードに年齢・性別・国籍・健康情報が無いのは仕様です — 保護属性は talent.policy/protected-attrs として評価根拠・帳票開示の両方から HARD ガードされています。

PolicyGovernor — HR-LLM の operation がどう検閲されるか

kaonavi 型 SaaS との違いはここです: HR-LLM(advisor) は提案しか返せず、コミット権は独立した PolicyGovernor が握ります(HARD violation は人間の承認でも覆せません)。下表はこのページの生成時に実際の OperationActor(StateGraph)を4回実行した結果です — HR-LLM 提案 → PolicyGovernor → phase gate → (必要なら)承認 interrupt → commit/hold。

operation	判定	根拠
op1 従業員DB upsert（HRBP が部署を更新・正当）	auto-commit	violation なし / confidence 0.97
op2 評価ドラフトが性別・婚姻を判断根拠に引用	HOLD	fairness 保護属性を判断根拠に使用: [:gender :marital]
op3 帳票 export（目的=headcount なのに病歴・年齢・性別の列を要求）	HOLD	minimal-disclosure 目的 :headcount に対し過剰な列: [:age :health :gender]
op4 サーベイ分析（e-002 離職リスク high・重大かつ低確信）	escalate → 人間承認可決 → commit	violation なし / confidence 0.55
op5 配置転換 — op4 の高リスク所見を受けたリテンション施策（e-002、根拠はサーベイ業務シグナルのみ）	escalate → 人間承認可決 → commit	violation なし / confidence 0.8
op5b 配置転換が年齢・通院を判断根拠に引用	HOLD	fairness 保護属性を判断根拠に使用: [:age :health]
op6 check 7: cites はクリーン、rationale に「女性で…」（実LLMの失敗様式） — 人間が却下	escalate → 人間レビュー却下 → HOLD	rationale-suspect 保護属性語を rationale に検出(SOFT — 抑圧でなく人間レビューに回し、人間が却下した)

監査台帳 — 上の4実行が実際に書いた追記専用レコード

SaaS では得られない不変の証跡。以下はハードコードではなく、ページ生成時の実 actor 実行が talent.store の台帳に書いた事実そのものです。

commit · op=:employee/upsert · actor=e-900 · subject=e-002 · basis=[:id :dept]
hold · op=:evaluation/draft · actor=e-900 · subject=e-001 · basis=[:fairness]
hold · op=:report/export · actor=e-900 · subject=* · basis=[:minimal-disclosure]
commit · op=:survey/analyze · actor=e-900 · subject=e-002 · basis=[:engagement :enps :free]
commit · op=:assignment/propose · actor=e-900 · subject=e-002 · basis=[:goals :dept :engagement :enps]
hold · op=:assignment/propose · actor=e-900 · subject=e-001 · basis=[:fairness]
hold · op=:evaluation/draft · actor=e-900 · subject=e-001 · basis=[:approver-rejected]

組織図 — ReportActor が実行後 Store から生成(kaonavi 組織図)

manager リンクからの純関数レンダリング。op5 のリテンション配置転換が反映済みです。

└ 田中 部長 (G5 / 営業)
  └ 佐藤 花子 (G3 / 営業)
  └ 鈴木 太郎 (G2 / カスタマーサクセス)

帳票 — 最小開示ゲートを通った CSV の実物

op3 の過剰開示(病歴・年齢・性別)は HOLD になりました。これは同じ :headcount 目的で最小開示ゲートが許す列だけを実際にレンダリングした帳票です — 保護属性の列はポリシー上ここに現れることができません(talent.policy/purpose-columns)。

id,name,grade,dept
e-001,佐藤 花子,:G3,営業
e-002,鈴木 太郎,:G2,カスタマーサクセス
e-100,田中 部長,:G5,営業

この人材ボードが保証すること

保護属性(年齢・性別・国籍・信条・健康・婚姻・妊娠)は評価根拠にならない(公正性ゲート)
帳票は宣言した目的に許された列しか出ない(最小開示ゲート)
role × 操作 × 対象関係の RBAC を LLM が迂回できない
等級変更・退職勧奨など高影響の操作は必ず人間の承認を経る
すべての commit / hold / 承認が追記専用の監査台帳に残る