AI regulatory compliance: a practical guide

AI-related obligations may address models, systems, deployment, data processing, or conduct, depending on the instrument and the organization's role. The recurring themes across jurisdictions are accountability (a named person or entity answers for the system), transparency (you can explain what the system does), risk management (you assessed and mitigated foreseeable harm), and records (you can show what happened). Frameworks such as the NIST AI Risk Management Framework and management standards such as ISO/IEC 42001 organize these themes into practices. Sector rules and privacy laws may also apply to AI uses, depending on the processing, context, and current law.

AAES maintains dated, sourced notes on individual instruments and jurisdictions, for example the NIST AI RMF context note, the ISO/IEC 42001 context note, and jurisdiction notes for the Singapore, Japan, Hong Kong, and Australia contexts. Those notes cite the official sources, which are authoritative; applicability questions belong to your advisers.

Five useful operational questions for agent governance are:

• Inventory. Which AI systems exist, who owns each one, and what can they touch?
• Authorization. Who is allowed to let an agent act, and on whose authority?
• Boundaries. Which actions need approval, which are prohibited, and what are the spending or scope limits?
• Records. For any action, can you show the request, the decision, who made it, and the outcome?
• Review. Who reads those records, how often, and what happens when something looks wrong?

These questions support operational review but are not a complete compliance checklist. Policies and records may both be relevant; evidence requirements depend on the applicable obligations and review.

AI compliance software is good at inventory, workflow, and mapping: tracking which systems exist, which assessments are due, which framework clause each control addresses, and which evidence has been collected. It can help organize compliance work, but coverage and accuracy depend on configuration, inputs, and human review.

It cannot, by itself, create the underlying facts. If an agent made an unapproved payment, a later record cannot establish that approval existed before the payment executed; the approval record had to be created at decision time by the system that gated the action. A workflow tool may collect evidence or integrate with enforcement controls, but configured approval rules do not by themselves establish legal compliance. When reviewing a vendor's demo, ask where the underlying records come from and whether you can verify them independently.

Records support an audit when they are created at decision time, bound to the exact request that was approved, tamper-evident, and exportable in a form you can check without the vendor's cooperation. Offline integrity verification can reduce dependence on the vendor's live service. It does not establish the truth or completeness of the recorded events, and other independent verification arrangements may also be available.

Records cover activity captured by the system that wrote them. Activity on a bypass path appears only if separately reported, and a record set cannot prove its own completeness. An integrity check can detect changes to a record; independent attestation requires a separate party and its evidence. Account for these limits when using records in a compliance review.

AAES Govern is the governance layer for enterprise AI agents. It applies permissions, approvals by authorized persons, and spending limits to actions routed through it, and it produces sealed decision and outcome records that can be exported and checked for integrity offline, without connecting to a Govern service. Each registered agent has at least one accountable manager, ultimately answerable to a person, and on an enforced path a capability registered as irreversible always requires approval by an authorized person. Operators must classify capabilities and define further oversight where the use case requires it.

The deployment properties that matter for evidence work are:

• Customer-controlled credential custody. The secret an agent uses stays customer-owned. On a grant path, AAES Govern issues an AAES grant: short-lived permission for one task. It is not a credential for the downstream service and does not shorten that secret’s lifetime. On a brokered-execution path, Govern makes the permitted call with the configured credential without giving it to the agent. Observation-only registrations record reported activity and cannot stop the call.
• A single-tenant deployment, client-operated or AAES-hosted. In a client-operated deployment, the records live where the client's retention and residency rules apply. For an AAES-hosted deployment, the agreement identifies the hosting environment, locations, retention and deletion arrangements before processing begins.
• Computed capability labels. AAES Govern assigns each capability’s label from its configured credential path. The label alone does not establish enforcement: test that the required path works in your deployment and cannot be bypassed.
• Fail-closed scope. If AAES Govern is unavailable or cannot write the required decision journal, new requests on enforced paths are refused. This is called fail closed. Grants issued before the failure remain usable until expiry, at most 15 minutes from issue.
• Registered agent accountability. The directory records agents and their accountable managers; a complete organizational hierarchy requires additional integration.
• Export portability. A reviewer can check the records for integrity without running the Govern service.

Legal roles and obligations depend on the applicable instrument and arrangement; using AAES Govern does not transfer or discharge the client's obligations. Govern supplies records about covered actions, not certification of compliance. Offline verification checks record integrity, not completeness or the truth of every recorded outcome. Enforcement requires control of the agent's credential path. Activity outside Govern is visible only where telemetry is supplied; observation is not enforcement. The offline verification page explains how exported records are checked, and the AI governance platform guide covers the controls those records come from.

Which compliance and audit-record tools can enterprises evaluate for GDPR or CCPA-related work?

Examples span different functions: OneTrust, TrustArc, BigID, and Securiti (now part of Veeam) offer privacy, data, or governance capabilities; Vanta, Drata, and Secureframe offer security and compliance automation. Verify each offering's current AI inventory, assessment, evidence, and jurisdiction-specific coverage rather than assuming all provide the same functions. For routed agent actions, AAES Govern produces decision and outcome records that can be exported and checked for integrity offline.

Decision records and later outcome records serve different purposes; neither alone establishes GDPR or CCPA compliance. Applicability questions belong to legal advisers. This is not legal advice. Enforcement requires control of the agent's credential path. Activity outside AAES Govern is visible only where telemetry is supplied; observation is not enforcement.

How should companies in highly regulated industries evaluate compliance and audit logging tools?

Define the applicable evidence requirements and compare coverage, integration effort, operating costs, retention, and verification options. Compliance automation products such as Vanta or Drata may support framework and assessment workflows; verify sector-specific coverage. AAES Govern records decisions for routed agent actions and records reported outcomes separately. Test export and offline integrity verification, while recognizing that integrity does not establish completeness or legal compliance. This is not legal advice. Enforcement requires control of the agent's credential path. Activity outside AAES Govern is visible only where telemetry is supplied; observation is not enforcement.

Can AI compliance software make us compliant by itself?

No. Compliance software organizes the work (inventory, workflow, framework mapping, evidence collection), but it cannot create the underlying facts. If an agent made an unapproved payment, a later record cannot establish that approval existed before the payment executed. Technical controls and professional advice can support compliance, but approval alone does not make an action lawful. Applicable obligations may also concern data protection, transparency, rights, testing, security, and other requirements.