部門別実践版
記事状態: 公開 · 最終確認: 未確認
要点
部門別のAI運用とは、営業用、人事用、法務用といった具合に別々のAIを並べることではない。共通のデータ境界、権限、正本、承認、評価、証跡の核(コア)を持ち、部門ごとに「何を正本とするか」「何をAIに入力してよいか」「どの判断を人間が引き受けるか」「どの外部作用を承認するか」「何を証拠として残すか」を上書きする。部門名だけで安全性が決まるのではなく、タスク、データ、意思決定の影響度、外部作用の組み合わせによって、人による確認・承認の基準を決める。
現在の判断
部門別のAI運用とは、営業用、人事用、法務用といった具合に別々のAIを並べることではない。共通のデータ境界、権限、正本、承認、評価、証跡の核(コア)を持ち、部門ごとに「何を正本とするか」「何をAIに入力してよいか」「どの判断を人間が引き受けるか」「どの外部作用を承認するか」「何を証拠として残すか」を上書きする。部門名だけで安全性が決まるのではなく、タスク、データ、意思決定の影響度、外部作用の組み合わせによって、人による確認・承認の基準を決める。
どこまで当てはまるか
部門別実践版
詳しく理解する
Department Profile — nine fields
- AUTHORITATIVE_SYSTEM — CRM / HRIS / ATS / ERP / 記録台帳 / DMS / Git / CI / dataset / protocol / CMS等、AI conversation/記憶情報の外部に置く正本。
- DATA_CLASS — 公開 / internal / confidential / personal / regulated / client / research-sensitive等。
- AI_ACTION_CLASS — READ / DRAFT / RECOMMEND / 書込み / EXTERNAL_EXECUTE。
- DECISION_IMPACT — low / material / high-impact-person decision。
- INPUT_GATE — allowed / approved-environment-only / redact-deidentify / prohibited。
- HUMAN_APPROVAL — none / light / mandatory specialist / dual 承認。
- OUTPUT_VALIDATION — 出典 check / numeric reconciliation / legal authority check / test / 記述・判断 substantiation等。
- 監査証跡 — 入力クラス、ソースの場所、モデル/モード、確認者、承認、最終アクション、成果物/バージョン。
- FAILURE-RECOVERY — 以前の状態へ戻す操作、訂正、notification、incident route。
Department overlays
- SALES — CRM、approved pricing/termsを正本化。提案草稿は許容しても価格・保証・性能記述・判断はapproved factsへ照合し、外部送信前承認を置く。
- GENERAL AFFAIRS — 一般文書・会議・社内規程検索を中心とするが、人事情報、契約、facility/security情報が混ざる場合はdata classで上位確認・承認の条件へ昇格する。部門名だけでリスクを決めない。
- HR(人事) — 候補者/従業員データ、高影響の意思決定、公平性・アクセシビリティ、理由の記録、および人による確認を強化します。自動スコアを最終決定に直結させないプロファイルを基本候補とします。EEOC(雇用機会均等委員会)の証拠は米国の文脈に基づくものであり、すべての法域へ一般化することはありません。
- 財務会計 — ERP、元帳、請求書を正本とする。生成された値ではなく、抽出、分類、照合の補助として扱い、記帳済みトランザクション、支払い、締め処理、外部報告には承認と証跡を要求する。監査の文脈を一般会計規則へ誤って一般化しないこと。
- 法務 — 事案 / DMS(文書管理システム) / 承認済み法務ソースを正本化する。機密入力、管轄区域/日付、主要な権限、引用の検証、弁護士による確認、外部への提出/通信に関する人による確認・承認を強化する。ABA(アメリカ法曹協会)のガイダンスが適用される法域および資格制度を分離する。
- DEVELOPMENT — repo / issue / CIを正本化。AI codeはbranch/diffとして扱い、秘密情報/dependency 適用限界、tests、static analysis、review、CI、公開・提供 承認、以前の状態へ戻す操作を要求する。
- RESEARCH — dataset / protocol / notebook / repositoryを正本化。IP/confidential/participant/条件を制御した dataの入力確認・承認の条件、方式/出典・来歴、citation、reproducibilityを要求する。NIH peer-reviewのNO-AI例を研究一般の禁止規則へ外挿しない。
- PR — CMS / approved messagingを正本化。公開 記述・判断、引用・画像権利、記述・判断 substantiation、brand/legal review、外部 publication 確認・承認の条件を強化する。
実装・運用
各部門のtaskは SAFE/LOW-RISK ASSIST、REVIEW-REQUIRED、RESTRICTED/NO-AI の3層で扱う。同じtask名でも確認・承認の条件は固定しない。「要約」でも公開marketing資料、未公開M&A legal matter、NIH peer-review materialではdata/impact/actionが異なる。
根拠 / 出典・来歴
権限 COMM-028-EA0026。NIST AI 600-1を共通コアへのコンテキスト・オーバーレイの根拠とし、米国EEOCを人事における高影響コンテキスト、ABA Formal Opinion 512を法的専門職の義務に関するコンテキスト、NIST SP 800-218Aを開発におけるセキュアなSDLCコンテキスト、NIH NOT-OD-23-149を研究における保護された入力/AI利用禁止コンテキスト、FTCの広告ガイダンスとWorkadoの執行を販売/広報の記述の正当性確認コンテキスト、PCAOBの証拠を監査/財務コンテキストとして扱う。法域、制度、専門職固有の証拠を普遍的な規則へ変換することはない。
利用できる条件
組織の確認・承認ゲート、ID・権限ゲート、データゲート、プラン・製品ゲート、アクションゲート、管轄・業界ゲート、エビデンスゲートを分離する。プロバイダー別のコネクタ、DLP、監査、保持、エージェント/アクション機能のプランにおける利用可能性は、本パケットでは確定せず、プロバイダーのマッピングによって再確認する。
確認・評価方法
共通モデルのベンチマークを部門プロファイルの合否判定に使用しないでください。部門ごとに「タスクの固定値 + 失敗コスト」を保持します。営業/広報は「未承認の記述・鮮度・送信ミス」、人事(HR)は「根拠の追跡可能性・公平性/アクセシビリティ経路・人による確認」、財務(Finance)は「数値の正確性・照合・記帳ミス」、法務(Legal)は「引用/権限・管轄区域/日付・機密保持・届出ミス」、開発(Development)は「テスト/セキュリティ/静的解析/機密情報の漏洩/差分/ロールバック」、研究(Research)は「出典・来歴/再現性/制限データの漏洩/捏造された参照」を候補指標とします。
確認・評価方法 2
未実施。各部門 3〜5 タスクとして、人工的に作成した機密性のないフィクスチャを用意し、同一のコア制御層で DRAFT(ドラフト) → VALIDATE(検証) → APPROVE(承認) → ACTION(実行) のプロセスを通す。実際の組織の利用環境データ、採用判断、支払い、法的提出、外部投稿は実行しない。未実施の結果や閾値を推測しない。
セキュリティとプライバシー
Security: 接続機能 権限を部門システム権限より広くせず、外部実行権限をread/draftと分離する。 プライバシー: 人事、法務、研究部門は入力データのクラスを明示し、承認された環境や、情報の編集/匿名化を人による確認・承認(ゲート)の対象とする。 監査: high-impact/外部/material actionsでは出典 資料内の該当箇所、reviewer、承認、final 成果物/バージョンを記録する。 Cost: 部門ごとに最上位モデルを固定せず、cost-routingはEA-017/018へ接続し、本packetでは単価を固定しない。 Operability: Department Profileのpolicy 担当者、review周期、incident routeを指定し、product/契約プラン/接続機能 利用可能性はas-of matrixへ分離する。
Cross-reference 適用限界
EA-019業務パターン、EA-024調達、EA-027業界別、EA-028教育カリキュラム、EA-029テンプレートへ接続する。ただし本packetで各EAを再編集・再解釈しない。
よくある失敗・反証
部門名はリスク classではない。Human-in-the-loopだけでは十分でなく、reviewerにauthoritative 出典、判断時間、専門性、reject/以前の状態へ戻す操作権限が必要である。AI conversation/記憶情報をCRM/ERP/HRIS/DMS/Git等の代替正本にしない。部門別ユースケースを無制限に増やさず、少数の高頻度task archetypeと高リスク確認・承認の条件へ絞る。
実務での使い方
組織の確認・承認ゲート、ID・権限ゲート、データゲート、プラン・製品ゲート、アクションゲート、管轄・業界ゲート、エビデンスゲートを分離する。プロバイダー別のコネクタ、DLP、監査、保持、エージェント/アクション機能のプランにおける利用可能性は、本パケットでは確定せず、プロバイダーのマッピングによって再確認する。
未実施。各部門 3〜5 タスクとして、人工的に作成した機密性のないフィクスチャを用意し、同一のコア制御層で DRAFT(ドラフト) → VALIDATE(検証) → APPROVE(承認) → ACTION(実行) のプロセスを通す。実際の組織の利用環境データ、採用判断、支払い、法的提出、外部投稿は実行しない。未実施の結果や閾値を推測しない。
Security: 接続機能 権限を部門システム権限より広くせず、外部実行権限をread/draftと分離する。 プライバシー: 人事、法務、研究部門は入力データのクラスを明示し、承認された環境や、情報の編集/匿名化を人による確認・承認(ゲート)の対象とする。 監査: high-impact/外部/material actionsでは出典 資料内の該当箇所、reviewer、承認、final 成果物/バージョンを記録する。 Cost: 部門ごとに最上位モデルを固定せず、cost-routingはEA-017/018へ接続し、本packetでは単価を固定しない。 Operability: Department Profileのpolicy 担当者、review周期、incident routeを指定し、product/契約プラン/接続機能 利用可能性はas-of matrixへ分離する。
まだ確認できていないこと
- EA-026-UNKNOWN-01
- 日本・EU・米国その他の部門別AI関連法規crosswalk。
- 経理・税務・給与・支払の具体的認可 matrix。
- プロバイダー別のコネクタ、DLP(データ流出防止)、監査、保持、agent/アクション機能の現在のプランにおける利用可能性。
- 総務の施設/セキュリティ/調達/記録などへのタスク分解。
- HRの公平性指標における法的・統計的な閾値。
- 部門別task fixtureの実測比較評価。 未確認事項を推測で閉じない。
- EA-026-UNKNOWN-CURRENTNESS
外部根拠の再確認日が正式な本文・公開管理情報で確定していないため、現行性は未確認のまま保持する。確認日を推測して補わない。
根拠資料
この記事には、直接開ける外部出典が登録されていません。出典IDや検証情報は末尾で確認できます。
出典ID・検証情報・機械可読データ
根拠の種類と情報の鮮度は、ラベルとアイコンで確認できます。
- 記事ID
- EA-026
- 最終確認日
- —
- 提供元・モデル・プラン・利用環境
- —
- 対象地域
- —
元資料の全文と収録照合記録
Public claim
部門別AI運用は、営業用・人事用・法務用と別々のAIを並べることではない。共通のデータ境界、権限、正本、承認、評価、証跡のCoreを持ち、部門ごとに「何を正本とするか」「何をAIへ入れてよいか」「どの判断を人間が引き受けるか」「どの外部作用を承認するか」「何を証拠として残すか」を上書きする。部門名だけで安全性は決まらず、task、data、decision impact、external actionの組合せでgateを決める。
Department Profile — nine fields
- AUTHORITATIVE_SYSTEM — CRM / HRIS / ATS / ERP / ledger / DMS / Git / CI / dataset / protocol / CMS等、AI conversation/memoryの外部に置く正本。
- DATA_CLASS — public / internal / confidential / personal / regulated / client / research-sensitive等。
- AI_ACTION_CLASS — READ / DRAFT / RECOMMEND / WRITE / EXTERNAL_EXECUTE。
- DECISION_IMPACT — low / material / high-impact-person decision。
- INPUT_GATE — allowed / approved-environment-only / redact-deidentify / prohibited。
- HUMAN_APPROVAL — none / light / mandatory specialist / dual approval。
- OUTPUT_VALIDATION — source check / numeric reconciliation / legal authority check / test / claim substantiation等。
- EVIDENCE-AUDIT — input class、source locator、model/mode、reviewer、approval、final action、artifact/version。
- FAILURE-RECOVERY — rollback、correction、notification、incident route。
Department overlays
- SALES — CRM、approved pricing/termsを正本化。提案草稿は許容しても価格・保証・性能claimはapproved factsへ照合し、外部送信前approvalを置く。
- GENERAL AFFAIRS — 一般文書・会議・社内規程検索を中心とするが、人事情報、契約、facility/security情報が混ざる場合はdata classで上位gateへ昇格する。部門名だけでriskを決めない。
- HR — candidate/employee data、高影響意思決定、公平性・accessibility、reason record、人間reviewを強化する。自動scoreを最終決定へ直結させないprofileを基本候補とする。EEOC evidenceは米国文脈であり全法域へ一般化しない。
- FINANCE-ACCOUNTING — ERP / ledger / invoiceを正本化。生成値ではなくextraction/classification/reconciliation補助として扱い、posted transaction、payment、close、external reportingには承認・証跡を要求する。監査文脈を一般会計規則へ誤一般化しない。
- LEGAL — matter / DMS / approved legal sourceを正本化。confidential input、jurisdiction/date、primary authority、citation verification、lawyer review、external filing/communication gateを強化する。ABA guidanceの適用法域・資格制度を分離する。
- DEVELOPMENT — repo / issue / CIを正本化。AI codeはbranch/diffとして扱い、secret/dependency boundary、tests、static analysis、review、CI、release approval、rollbackを要求する。
- RESEARCH — dataset / protocol / notebook / repositoryを正本化。IP/confidential/participant/controlled dataの入力gate、method/provenance、citation、reproducibilityを要求する。NIH peer-reviewのNO-AI例を研究一般の禁止規則へ外挿しない。
- PR — CMS / approved messagingを正本化。public claim、引用・画像権利、claim substantiation、brand/legal review、external publication gateを強化する。
Three operational tiers
各部門のtaskは SAFE/LOW-RISK ASSIST、REVIEW-REQUIRED、RESTRICTED/NO-AI の3層で扱う。同じtask名でもgateは固定しない。「要約」でも公開marketing資料、未公開M&A legal matter、NIH peer-review materialではdata/impact/actionが異なる。
Evidence / provenance
AUTHORITY COMM-028-EA0026。NIST AI 600-1を共通Coreへのcontext overlay根拠、米国EEOCをHR high-impact context、ABA Formal Opinion 512をlegal professional-duty context、NIST SP 800-218Aをdevelopment secure-SDLC context、NIH NOT-OD-23-149をresearch protected-input/no-AI context、FTC advertising guidanceとWorkado enforcementをSales/PR claim-substantiation context、PCAOB evidenceをaudit/finance contextとして扱う。法域・制度・専門職固有の証拠を普遍規則へ変換しない。
Availability gates
Organization gate、Identity/permission gate、Data gate、Plan/product gate、Action gate、Jurisdiction/industry gate、Evidence gateを分離する。provider別connector、DLP、audit、retention、agent/action機能のplan availabilityは本packetでは確定せず、provider mappingで再確認する。
Failure envelope
部門名はrisk classではない。Human-in-the-loopだけでは十分でなく、reviewerにauthoritative source、判断時間、専門性、reject/rollback権限が必要である。AI conversation/memoryをCRM/ERP/HRIS/DMS/Git等の代替正本にしない。部門別ユースケースを無制限に増やさず、少数の高頻度task archetypeと高リスクgateへ絞る。
Evaluation
共通model benchmarkをDepartment Profileの合否に使用しない。task fixture + failure-costを部門別に持つ。Sales/PRはunsupported claim・freshness・send escape、HRはrationale traceability・fairness/accessibility route・human override、Financeはnumeric exactness・reconciliation・posting escape、Legalはcitation/authority・jurisdiction/date・confidentiality・filing escape、Developmentはtests/security/static analysis/secret leakage/diff/rollback、Researchはprovenance/reproducibility/restricted-data leakage/fabricated-referenceを候補指標とする。
TEST_PROFILE
UNEXECUTED。synthetic/non-sensitive fixturesを各部門3〜5 task用意し、同一Core controlで DRAFT → VALIDATE → APPROVE → ACTION を通す。実tenant data、採用判断、支払、法的提出、外部投稿は実行しない。未実施結果や閾値を推測しない。
Security / privacy / audit / cost / operability
Security: connector permissionを部門system権限より広くせず、外部実行権限をread/draftと分離する。 Privacy: HR、legal、researchはinput data classを明示し、approved environmentやredaction/de-identificationをgate化する。 Audit: high-impact/external/material actionsではsource locator、reviewer、approval、final artifact/versionを記録する。 Cost: 部門ごとに最上位modelを固定せず、cost-routingはEA-017/018へ接続し、本packetでは単価を固定しない。 Operability: Department Profileのpolicy owner、review周期、incident routeを指定し、product/plan/connector availabilityはas-of matrixへ分離する。
OPEN_UNKNOWN
- 日本・EU・米国その他の部門別AI関連法規crosswalk。
- 経理・税務・給与・支払の具体的authorization matrix。
- provider別connector、DLP、audit、retention、agent/action機能の現行plan availability。
- 総務のfacility/security/procurement/records等へのtask分解。
- HR fairness metricsの法的・統計的閾値。
- 部門別task fixtureの実測benchmark。 UNKNOWNを推測で閉じない。
Cross-reference boundary
EA-019業務パターン、EA-024調達、EA-027業界別、EA-028教育カリキュラム、EA-029テンプレートへ接続する。ただし本packetで各EAを再編集・再解釈しない。
EA-026-R11-RESEARCH研究資料研究資料根拠の出所: AUDITED_CANONICAL_RESEARCH_PACKETEA-026 監査済みresearch / canonical revision binding
- 裏付ける内容
- 部門別AI運用は、営業用・人事用・法務用と別々のAIを並べることではない。共通のデータ境界、権限、正本、承認、評価、証跡のCoreを持ち、部門ごとに「何を正本とするか」「何をAIへ入れてよいか」「どの判断を人間が引き受けるか」「どの外部作用を承認するか」「何を証拠として残すか」を上書きする。部門名だけで安全性は決まらず、task、data、decision impact、external actionの組合せでgateを決める。
- 確認日
- —
- 出典・実験ID
- COMM-028-EA0026
- 検証箇所
- COMM-028-EA0026 · EA-026-R5-LEGACY-MIGRATION-20261008-R1 · content/staging/EA-026.md
- 適用範囲
- 監査済みEA本文・canonical revision・既存Source Graph relationの範囲。欠損currentnessは推測で閉じない。
- 出典・来歴
- AUDIT_PASS_CANONICAL_BINDING
- 限界
- canonical監査・revision bindingの存在を示す。外部ソースcurrentnessが本文またはcontrol-planeで確定していない場合は、currentnessをUNKNOWNのまま保持する。
EA-026-R11-WEB-READBACK実装資料実装資料根拠の出所: IMPLEMENTATION_READBACKEA-026 Web body identity / canonical readback
- 裏付ける内容
- canonical staging bodyのSHA-256一致とR9 canonical ledger readbackをProduction projectionの入力として検証する。
- 確認日
- —
- 出典・実験ID
- WEBBODY-EA0026-R8-063BC238
- 検証箇所
- WEBBODY-EA0026-R8-063BC238 · content/staging/EA-026.md · EA-026-R5-LEGACY-MIGRATION-20261008-R1
- 適用範囲
- R9/R10 canonical readback後のProduction生成時body identity。
- 出典・来歴
- CANONICAL_READBACK_BODY_HASH_MATCH
- 限界
- body identity/readbackは本文claim自体の真偽や外部ソースの最新性を追加保証しない。
- 出典ID
- COMM-028-EA0026, WEBBODY-EA0026-R8-063BC238
- 追跡中のUNKNOWN ID
- EA-026-UNKNOWN-01, EA-026-UNKNOWN-CURRENTNESS
- 再確認のきっかけ
- 正式な 改訂版/publication 状態 change · 本文 成果物 hash change · 出典 現行性 change · new contradiction or 実装 結果の照合
機械検査: 通過 — 機械検査の結果です。情報の正確性や実行の承認を保証するものではありません。
同じ記事IDの機械可読データです。