要旨
国際監査基準 (ISA) および JICPA 基準で成文化された監査手順は、基本的に散文を装った実行可能な仕様です。各規格では、前提条件、必要な証拠、決定ロジック、事後条件が定義されており、これはソフトウェア機能と同じ構造です。しかし、監査の実施は依然として手動の紙ベースのプロセスであり、経験豊富な専門家が文書化された標準をその場限りのワークフローに変換するため、トレーサビリティが失われ、すべてのステップで不整合が生じます。
このペーパーでは、Audit Universe Runtime を紹介します。これは、監査手順を第一級のランタイム操作として扱う MARIA OS ガバナンス フレームワーク内のマルチエージェント実行エンジンです。当社は、ISA および JICPA の標準を型付きのエージェント タスク定義にコンパイルし、不変の監査証跡を備えた管理されたパイプラインを通じて実行し、正確に定義された重要性のしきい値で人間とエージェントのコラボレーションを調整します。その結果、「AI が監査人に取って代わる」のではなく、監査手続きが人間の権限の下で自動的に実行され、すべての判断判断が追跡可能で、すべてのサンプルが統計的に正当化され、すべての結論がその裏付けとなる証拠と正式に関連付けられることになります。
1. 実行可能な仕様としての監査手順
Audit Universe Runtime を推進する洞察は構造的なものです。ISA 標準には、実行可能プログラムのセマンティクスがすでに含まれています。 ISA 500 (監査証拠) を考えてみましょう。監査人は、十分かつ適切な監査証拠を入手するための監査手順を設計し、実行しなければならないと規定しています。これは、(a) 証拠十分性述語、(b) 証拠適切性分類子、(c) 手順選択関数、および (d) 実行プロトコルに分解されます。
この分解を 監査手順仕様 (APS) として形式化します。
// Audit Procedure Specification — compiled from ISA/JICPA standards
interface AuditProcedureSpec {
id: string // e.g., "ISA-500-AP-03"
standard: "ISA" | "JICPA"
standardRef: string // e.g., "ISA 500.6(a)"
preconditions: PredicateExpr[] // Must all hold before execution
requiredEvidence: EvidenceRequirement[]
samplingStrategy: SamplingConfig
assertionsCovered: AuditAssertion[] // Existence, Completeness, Valuation, etc.
executionSteps: ProcedureStep[]
postConditions: PredicateExpr[] // Must all hold after execution
materialityThreshold: MonetaryAmount
humanGate: GateConfig // When to escalate to human auditor
}
interface ProcedureStep {
order: number
action: AgentAction
evidenceOutput: EvidenceType
failMode: "halt" | "flag" | "escalate"
timeout: Duration
coordinate: MARIACoordinate // Agent responsible for this step
}
type AuditAssertion =
| "existence"
| "completeness"
| "valuation"
| "rights_and_obligations"
| "presentation_and_disclosure"
| "accuracy"
| "cutoff"
| "classification"各 ISA 標準は 1 つ以上の APS 定義に解析されます。コンパイル プロセスは生成的ではありません。これは、標準の標準要件から型付きインターフェイスへの構造マッピングです。標準で「監査人は行うものとする」と規定されている場合、「failMode: "halt"」を指定した「ProcedureStep」を生成します。 「監査人は考慮すべきである」と書かれている部分では、failMode: "flag" とヒューマン ゲートを備えたステップを生成します。
2. エージェントタスクへの ISA/JICPA 標準マッピング
Audit Universe は、エージェントのタスク仕様にマッピングされたすべての ISA および JICPA 標準のコンパイルされたデータベースである 標準レジストリ を維持します。レジストリはバージョン管理されており、不変です。標準が更新されると、新しいバージョンが追加され、上書きされることはなく、過去の取り組みにどのバージョンの標準が適用されているかを示す機能が保持されます。
| Standard | Agent Task Domain | Assertions Covered | Agent Count |
|----------|------------------|-------------------|-------------|
| ISA 240 | Fraud Risk Assessment | All | 3 |
| ISA 315 | Risk Identification & Assessment | All | 5 |
| ISA 330 | Responses to Assessed Risks | All | 4 |
| ISA 500 | Evidence Collection & Evaluation | All | 6 |
| ISA 520 | Analytical Procedures | Completeness, Valuation | 2 |
| ISA 530 | Audit Sampling | All (indirect) | 3 |
| ISA 540 | Accounting Estimates | Valuation, Completeness | 4 |
| ISA 550 | Related Party Transactions | Existence, Disclosure | 2 |
| ISA 570 | Going Concern Assessment | All | 3 |
| JICPA IT | IT General Controls Testing | Completeness, Accuracy | 4 |
| JICPA QC | Quality Control Standards | N/A (meta) | 2 |各エージェント タスクは、MARIA 座標系から責任制約を継承します。座標「G1.U2.P1.Z1.A3」の ISA 315 リスク評価エージェントは、明示的なクロスゾーン許可がなければ、ゾーン境界外の証拠にアクセスできません。これにより、ISA 220 が要求する職務の分離が強制されます。
3. 証拠収集の自動化
証拠は監査の基本通貨です。 Audit Universe Runtime は、監査証拠の取得、検証、サポートするアサーションへのリンクを自動化する 証拠収集エンジン を実装します。
interface EvidenceBundle {
id: string
engagementId: string
procedureRef: string // Links to AuditProcedureSpec.id
assertionsCovered: AuditAssertion[]
sources: EvidenceSource[]
collectedAt: ISOTimestamp
collectedBy: MARIACoordinate // Agent coordinate
verificationStatus: "unverified" | "auto_verified" | "human_verified"
hashChain: string // SHA-256 chain for immutability
sufficiencyScore: number // 0.0 - 1.0
appropriatenessScore: number // 0.0 - 1.0
}
interface EvidenceSource {
type: "erp_extract" | "bank_confirmation" | "document_scan"
| "external_api" | "management_representation" | "recomputation"
rawPayload: EncryptedBlob
extractedAt: ISOTimestamp
sourceSystem: string
reconciliationKey: string // For cross-referencing
}
// Evidence sufficiency is evaluated continuously
function evaluateSufficiency(
bundle: EvidenceBundle,
requirement: EvidenceRequirement,
materialityThreshold: MonetaryAmount
): SufficiencyResult {
const coverage = computeAssertionCoverage(bundle, requirement)
const reliability = assessSourceReliability(bundle.sources)
const sufficiency = coverage * reliability
return {
score: sufficiency,
sufficient: sufficiency >= requirement.minimumThreshold,
gaps: identifyEvidenceGaps(bundle, requirement),
recommendation: sufficiency < 0.7
? "additional_procedures_required"
: "sufficient"
}
}このエンジンは プル モデル で動作します。監査手順で証拠が必要な場合、入力された証拠リクエストを発行します。証拠収集エンジンは、接続されたソース システム (ERP、銀行ポータル、文書管理) にクエリを実行し、抽出トランスフォーマーを適用して、検証済みの「EvidenceBundle」を返すことによってリクエストを解決します。すべてのバンドルはハッシュチェーン化されており、収集後の改ざんを防ぎます。
4. 戦略エージェントのサンプリング
ISA 530 では、結論に対する合理的な根拠を提供するように監査サンプリングを設計することが求められています。 Audit Universe ランタイムは、統計的に有効なサンプル サイズを計算し、適切な方法を使用してサンプルを選択し、許容可能な虚偽表示のしきい値に対して結果を評価する専用の サンプリング戦略エージェント を実装します。
サンプリングの決定は次のように形式化されます。
n = \frac{N \cdot z_{\alpha/2}^2 \cdot p(1-p)}{(N-1) \cdot e^2 + z_{\alpha/2}^2 \cdot p(1-p)}ここで、N は母集団サイズ、z は信頼係数、p は予想される誤差率、e は許容誤差です。サンプリング エージェントは、関連するアサーションに対する重大な虚偽表示の評価されたリスクに基づいて、これらのパラメータを動的に調整します。
interface SamplingDecision {
method: "monetary_unit" | "classical_variable" | "attribute" | "stratified"
populationSize: number
sampleSize: number
confidenceLevel: number // e.g., 0.95
tolerableError: MonetaryAmount
expectedError: MonetaryAmount
riskOfMaterialMisstatement: "low" | "moderate" | "high"
selectionMethod: "random" | "systematic" | "haphazard" | "stratified_random"
stratification?: StratificationConfig
projectedMisstatement?: MonetaryAmount // After evaluation
}
// Monetary Unit Sampling (MUS) — preferred for overstatement testing
function computeMUSSampleSize(
bookValue: number,
materialityThreshold: number,
confidenceLevel: number,
expectedMisstatement: number
): number {
const reliabilityFactor = getReliabilityFactor(confidenceLevel, 0)
const adjustedMateriality = materialityThreshold - expectedMisstatement
return Math.ceil((bookValue * reliabilityFactor) / adjustedMateriality)
}重要なのは、サンプリング エージェントは単にサンプル サイズを計算するだけではなく、選択されたパラメーターを評価されたリスク レベル、母集団の性質、テスト対象の特定の主張に結び付ける「SamplingRationale」文書を作成することによって、あらゆるサンプリングの決定を正当化するということです。この理論的根拠は、不変の監査証跡の一部になります。
5. リスク評価のランタイム
ISA 315 (2019 年改訂) では、監査人が事業体とその環境を理解することで、重大な虚偽表示のリスクを特定し、評価することが求められています。リスク評価ランタイムは、これをポイントインタイムの演習ではなく継続的な評価エンジンとして実装します。
Traditional audit treats risk assessment as a planning-phase activity. The Audit Universe Runtime evaluates risk continuously — as evidence is collected, as transactions are processed, and as anomalies are detected. Risk scores are living values that trigger re-evaluation of audit responses in real time.リスク モデルは、ISA 315 の構造に従って 3 つの層に分解されます。
AR = IR \times CR \times DRAR は監査リスク、IR は固有リスク、CR は管理リスク、DR は検出リスクです。ランタイムはこれらを離散的なカテゴリではなく連続的な変数として維持するため、監査応答強度の正確な調整が可能になります。
interface RiskAssessment {
entityId: string
assessmentCycle: number
inherentRisk: RiskVector // Per-assertion risk scores
controlRisk: RiskVector // Evaluated from control testing
detectionRisk: RiskVector // Computed to achieve target audit risk
significantRisks: SignificantRisk[]
riskResponses: RiskResponse[] // ISA 330 responses
lastUpdated: ISOTimestamp
triggerEvents: RiskTriggerEvent[] // What caused re-assessment
}
interface RiskVector {
existence: number // 0.0 - 1.0
completeness: number
valuation: number
rights: number
presentation: number
accuracy: number
cutoff: number
classification: number
}リスクスコアが事前定義されたしきい値を超えると、ランタイムは計画された監査対応を自動的に調整します。つまり、サンプルサイズを増やしたり、実質的な手順を追加したり、責任ゲートを介して人間のパートナーレビューにエスカレーションしたりします。
6. 実体試験実行エンジン
実質的な手順、つまり詳細のテストと実質的な分析手順は、監査証拠収集の中核を形成します。実行エンジンは、依存関係の順序と証拠の前提条件を尊重して、これらを並列エージェント ワークフローとして調整します。
エンジンはステート マシンを通じて実質的なテストを処理します。
type SubstantiveTestState =
| "queued"
| "prerequisites_checking"
| "sampling"
| "executing"
| "evaluating_results"
| "anomaly_review"
| "concluded"
| "escalated"
interface SubstantiveTestExecution {
procedureId: string
state: SubstantiveTestState
sampleSelected: SamplingDecision
itemsTested: number
itemsWithExceptions: number
projectedMisstatement: MonetaryAmount
conclusionReached: boolean
evidenceBundles: EvidenceBundle[]
anomaliesDetected: AnomalyRecord[]
validTransitions: Map<SubstantiveTestState, SubstantiveTestState[]>
}
// State machine enforces valid transitions
const VALID_TRANSITIONS: Record<SubstantiveTestState, SubstantiveTestState[]> = {
queued: ["prerequisites_checking"],
prerequisites_checking: ["sampling", "escalated"],
sampling: ["executing"],
executing: ["evaluating_results"],
evaluating_results: ["concluded", "anomaly_review", "escalated"],
anomaly_review: ["concluded", "escalated"],
concluded: [],
escalated: ["queued"] // Can be re-queued after human review
}各実質的なテストでは、予想される虚偽表示、口座残高が重大な虚偽表示である可能性の評価、および結論を裏付ける一連の証拠を含む正式な結論が得られます。このエンジンは、証拠十分性スコアが関連するアサーションの最小しきい値を満たさない限り、テストが「結論済み」状態に達することを防ぎます。
7. 監査証跡の不変性
監査証拠の完全性は、証拠、結論、または決定が検出されずに事後に変更されないという保証に依存します。 Audit Universe ランタイムは、ハッシュ チェーン証拠台帳 を通じて不変性を実装します。
interface AuditTrailEntry {
sequence: number
timestamp: ISOTimestamp
actorCoordinate: MARIACoordinate
action: AuditAction
payload: EncryptedPayload
previousHash: string
currentHash: string // SHA-256(sequence + timestamp + action + payload + previousHash)
signature: AgentSignature // Cryptographic signature of acting agent
}
function appendToTrail(
trail: AuditTrailEntry[],
action: AuditAction,
payload: unknown,
actor: MARIACoordinate
): AuditTrailEntry {
const previous = trail[trail.length - 1]
const entry: AuditTrailEntry = {
sequence: previous.sequence + 1,
timestamp: getCurrentTimestamp(),
actorCoordinate: actor,
action,
payload: encrypt(payload),
previousHash: previous.currentHash,
currentHash: "",
signature: signWithAgentKey(actor)
}
entry.currentHash = computeHash(entry)
return entry
}
// Verification: detect any tampering in the chain
function verifyTrailIntegrity(trail: AuditTrailEntry[]): IntegrityResult {
for (let i = 1; i < trail.length; i++) {
const recomputed = computeHash({ ...trail[i], currentHash: "" })
if (recomputed !== trail[i].currentHash) {
return { valid: false, brokenAt: i, reason: "hash_mismatch" }
}
if (trail[i].previousHash !== trail[i - 1].currentHash) {
return { valid: false, brokenAt: i, reason: "chain_break" }
}
}
return { valid: true }
}実行時のすべてのアクション (証拠の収集、サンプリングの決定、リスクの再評価、テストの結論、人間によるオーバーライド) は、ハッシュ チェーンにエントリを追加します。チェーンは、契約終了時、品質審査チェックポイント、および規制調査時に検証されます。各エントリには前のエントリのハッシュが含まれているため、履歴レコードを変更すると、後続のチェーン全体が無効になります。
8. 監査人とエージェントのコラボレーションモデル
Audit Universe Runtime は、人間の監査員に代わることを目的としたものではありません。 段階的なコラボレーション モデルを実装しており、エージェントが手続きの実行を処理し、判断が必要な決定については人間が権限を保持します。
| Decision Type | Agent Authority | Human Authority | Gate Trigger |
|--------------|----------------|-----------------|-------------|
| Sample selection from computed parameters | Full | None | None |
| Evidence extraction from source systems | Full | Review on exception | Source unavailable |
| Routine reconciliation (< materiality/10) | Full | Spot-check | None |
| Anomaly classification | Propose | Confirm/Override | Always |
| Risk assessment adjustment | Propose | Approve | Risk increase > 0.15 |
| Significant risk identification | Flag | Decide | Always |
| Going concern evaluation | Compile evidence | Full authority | Always |
| Audit opinion formation | Compile summary | Full authority | Always |
| Engagement partner sign-off | N/A | Full authority | Always |The collaboration model embodies MARIA OS's core thesis. Agents execute the 80% of audit procedures that are deterministic — extraction, reconciliation, recalculation, sampling. Humans focus on the 20% that requires professional judgment — risk assessment, anomaly interpretation, going concern evaluation, and opinion formation.コラボレーションは、MARIA OS 責任ゲートを通じて強制されます。エージェントがその権限レベルを超える意思決定ポイントに到達すると、ゲートは実行を停止し、事前にコンパイルされた証拠パッケージを使用して適切な人間の監査人に決定をルーティングします。人間の決定は不変の証跡に記録され、人間のアイデンティティに起因し、人間が検討した証拠に関連付けられます。
9. 監査中のリアルタイムの異常検出
従来の監査では、テスト完了後の証拠評価中に、遡及的に異常を発見します。 Audit Universe ランタイムは、証拠の収集と実質的なテストと同時に動作する ストリーミング異常検出 を実装します。
interface AnomalyDetector {
type: "statistical" | "pattern" | "temporal" | "relational"
threshold: number
windowSize: number // Number of transactions in sliding window
detect(stream: TransactionStream): AsyncIterable<AnomalyCandidate>
}
interface AnomalyCandidate {
transactionIds: string[]
anomalyType: AnomalyClassification
severity: "low" | "medium" | "high" | "critical"
confidence: number // 0.0 - 1.0
explanation: string
suggestedProcedure: string // Additional audit procedure to perform
relatedAssertions: AuditAssertion[]
}
type AnomalyClassification =
| "benford_violation" // Digit distribution anomaly
| "round_number_excess" // Unusual frequency of round amounts
| "timing_anomaly" // Transactions clustered near period-end
| "counterparty_concentration" // Unusual concentration of counterparties
| "reversal_pattern" // Entry-reversal patterns suggesting manipulation
| "segregation_violation" // Same actor in incompatible roles
| "threshold_manipulation" // Amounts just below approval thresholds
| "journal_entry_anomaly" // Unusual manual journal entries異常検出システムは 4 つの並列検出器を実行します。 統計検出器は、ベンフォードの法則分析、比率分析、分布テストを適用します。 パターン検出器は、既知の不正行為の兆候 (ラウンドナンバーバイアス、しきい値操作) を特定します。 時間検出器は、期間境界付近に集中しているトランザクションや異常な時間に投稿されたトランザクションにフラグを立てます。 リレーショナル ディテクタ は、取引ネットワークをマッピングして、異常な取引相手のパターンや循環フローを特定します。
重大度「高」以上の異常が検出されると、ランタイムは直ちにヒューマン ゲートをトリガーし、監査人が発見を確認するまで関連する自動化手順を一時停止します。
10. 監査の完全性の正式モデル
監査における基本的な質問は、「十分な作業を行ったか」ということです。 Audit Universe Runtime は、監査の完全性を主観的に評価するのではなく検証できる数学的特性として形式化します。
監査完全性関数 C(E, A, M) を定義します。
C(E, A, M) = \min_{a \in A} \left( \frac{\sum_{e \in E_a} w(e) \cdot r(e)}{\theta(a, M)} \right)E は収集されたすべての証拠のセット、A は対象となるすべての主張のセット、M は重要性のしきい値、E_a は主張 a に関連する証拠のサブセット、w(e) は証拠項目 e の重み (情報源の信頼性に基づく)、r(e) は証拠 e の主張 a に対する関連性スコア、theta(a, M) は、重要性レベル M のアサーション a の十分性しきい値です。
すべての物品勘定残高および取引クラスについて C(E, A, M) >= 1.0 の場合、監査は完了します。この関数は証拠が蓄積されるにつれて継続的に計算され、監査完了に向けたリアルタイムの進捗指標を提供します。
If evidence collection is non-destructive (no evidence is discarded) and evidence weights are non-negative, then C(E, A, M) is monotonically non-decreasing during the engagement. This guarantees that progress toward completeness is irreversible — a property that traditional audit cannot formally assert.11. 継続的監査と定期的監査エージェント
Audit Universe ランタイムは、定期モード (従来のエンゲージメント ベースの監査) と 継続モード (ローリング証拠の蓄積によるリアルタイム監視) の 2 つの実行モードをサポートしています。
| Dimension | Periodic Agents | Continuous Agents |
|-----------|----------------|-------------------|
| Activation | Engagement start date | Always running |
| Evidence window | Fiscal period | Rolling 30/90/365 day |
| Risk re-assessment | Planning phase only | Every risk trigger event |
| Sample selection | Once per cycle | Adaptive resampling |
| Anomaly detection | Batch post-collection | Streaming real-time |
| Human review cadence | Milestone-based | Threshold-triggered |
| Report output | Engagement close | Daily/weekly dashboards |
| Cost model | Per-engagement fee | Subscription retainer |継続的な監査エージェントには、証拠の古さという新たな課題が生じます。企業の管理環境が変化した場合、6 か月前に収集された証拠は現在の主張を裏付けるものではなくなる可能性があります。ランタイムは、証拠減衰関数 を通じてこれに対処します。
w_t(e) = w_0(e) \cdot e^{-\lambda(t - t_e)}ここで、w_t(e) は時刻 t における証拠 e の重み、w_0(e) は収集時刻 t_e における初期重み、lambda はソース システムのボラティリティによって決定される減衰率です。ボラティリティの高いソース (現金残高、在庫数) は、ボラティリティの低いソース (固定資産台帳、長期債務契約) よりも減衰率が高くなります。
証拠の重みが十分性のしきい値を下回ると、継続的エージェントが自動的に再収集をトリガーし、手動でスケジュールを設定しなくても監査の完全性を維持します。
12. 品質レビューゲートとエンゲージメント管理オーケストレーション
Audit Universe Runtime は、ISA 220 品質管理要件を MARIA OS 責任フレームワーク内の正式なゲート構造として実装します。
// MARIA Coordinate Mapping to Audit Engagement Structure
// Galaxy = Audit Firm
// Universe = Engagement (client audit)
// Planet = Audit Domain (Revenue, Expenses, Assets, Liabilities, Equity)
// Zone = Account Group (e.g., Trade Receivables, Allowances)
// Agent = Individual procedure executor
interface EngagementOrchestrator {
coordinate: MARIACoordinate // G1.U2 (Firm.Engagement)
engagementPartner: HumanIdentity
engagementQualityReviewer: HumanIdentity
planets: AuditDomain[]
qualityGates: QualityGate[]
timeline: EngagementTimeline
}
interface QualityGate {
id: string
name: string
trigger: "milestone" | "risk_event" | "completeness_threshold"
reviewLevel: "manager" | "partner" | "eqr" // Engagement Quality Reviewer
requiredEvidence: string[]
approved: boolean
approvedBy?: HumanIdentity
approvedAt?: ISOTimestamp
}
// Engagement lifecycle as state machine
type EngagementPhase =
| "planning"
| "risk_assessment"
| "control_testing"
| "substantive_testing"
| "completion"
| "reporting"
| "archiving"
const ENGAGEMENT_GATES: Record<EngagementPhase, QualityGate[]> = {
planning: [
{ id: "QG-01", name: "Engagement Acceptance", trigger: "milestone",
reviewLevel: "partner", requiredEvidence: ["independence_confirmation",
"risk_acceptance_memo", "engagement_letter"], approved: false }
],
risk_assessment: [
{ id: "QG-02", name: "Risk Assessment Approval", trigger: "milestone",
reviewLevel: "manager", requiredEvidence: ["risk_assessment_summary",
"significant_risks_memo"], approved: false }
],
control_testing: [
{ id: "QG-03", name: "Control Deficiency Review", trigger: "risk_event",
reviewLevel: "partner", requiredEvidence: ["control_test_results",
"deficiency_classification"], approved: false }
],
substantive_testing: [
{ id: "QG-04", name: "Substantive Completion Review", trigger: "completeness_threshold",
reviewLevel: "manager", requiredEvidence: ["completeness_matrix",
"misstatement_summary"], approved: false }
],
completion: [
{ id: "QG-05", name: "Engagement Quality Review", trigger: "milestone",
reviewLevel: "eqr", requiredEvidence: ["full_evidence_package",
"opinion_draft", "significant_judgments_memo"], approved: false }
],
reporting: [
{ id: "QG-06", name: "Report Issuance Authorization", trigger: "milestone",
reviewLevel: "partner", requiredEvidence: ["signed_representations",
"final_analytics", "subsequent_events_review"], approved: false }
],
archiving: []
}エンゲージメント オーケストレーターは、エンゲージメント ユニバース内のすべてのエージェントを調整し、フェーズの順序付け、ゲート クリアランス、およびリソースの割り当てを強制します。リスク評価ゲート (QG-02) が人間のマネージャーによって承認されるまで、エージェントは実質的なテストを開始できません。エンゲージメント品質レビュー ゲート (QG-05) が EQR (エンゲージメント チームから独立した人間) によって承認されるまで、監査レポートは発行できません。
このアーキテクチャにより、Audit Universe ランタイムは、高度な自動化にもかかわらず、専門標準が必要とする人間の権限構造を確実に維持します。エージェントは手順を実行します。人間は判断を下します。この制度により、いかなる判決も回避されず、証拠が失われず、形式的に十分な証拠がなければ結論に達しないことが保証されます。
結論
Audit Universe Runtime は、監査手順が単に自動化に適しているだけではなく、その本質的な構造において、すでに実行可能な仕様であることを示しています。 ISA および JICPA 標準は、前提条件、証拠要件、意思決定ロジック、および品質ゲートを、エージェントのタスク仕様にコンパイルするのに十分な精度で定義しています。欠けているのは、監査ロジックの形式化ではなく、それを安全に実行するための ガバナンス インフラストラクチャです。つまり、不変の監査証跡、責任ゲート、段階的な人間とエージェントのコラボレーション、形式的な完全性検証です。
MARIA OS はこのインフラストラクチャを提供します。エンゲージメント構造を MARIA 座標系にマッピングし、管理されたステート マシンとして監査手順を実装し、重要性を重視するすべての意思決定ポイントで人間の権限を強制することにより、監査ユニバース ランタイムは、完全な手動または完全に自動化されたアプローチでは不可能なことを達成します。完全性の数学的保証と不変の証拠チェーンを備え、人間の権限の下で自動的に実行される監査手順。
監査の未来は、人工知能が専門家の判断に取って代わることではありません。これは、すべての手順を追跡可能にし、すべてのサンプルを擁護可能にし、すべての結論を証拠に正式にリンクさせる、インテリジェントなランタイムを通じて機能する専門的な判断です。