Compliance

Compliance reviews need evidence from the systems under review. The platform should produce that evidence during operation so teams do not have to reconstruct it after an auditor sends a request list.

Recurring audit work

When an audit starts, teams may assemble an AI inventory by asking around and then use general-purpose logs to reconstruct system activity. That includes access, data use, and approvals. The work takes weeks and produces partial evidence. It recurs when the underlying systems still do not produce the required records.

Controls need records that show when and how they operated. Without those records, an auditor cannot distinguish an executed control from a control that did not run.

Common evidence requests

Evidence requests across the frameworks below include:

• Maintain an inventory of AI systems, their purposes, data, and owners through the Build and Control processes.
• Use ingress and identity records to show who could access each system and who did.
• Record changes and approvals through configuration.
• Use traces to record processing performed on behalf of a person.
• Apply storage policies that record retention and deletion.
• Record which providers process organizational data and the applicable terms.

Selected frameworks

These notes provide operational context and are not legal advice.

SOC 2

SOC 2 examines whether stated controls operate. AI systems are in scope when they touch systems in scope. AI tools adopted outside the normal path may be missing from the system description and inventory.

HIPAA

HIPAA requirements depend on whether protected health information reaches the model. If it does, the endpoint needs coverage under an applicable Business Associate Agreement. Routing should enforce which endpoints are covered.

PCI DSS

PCI DSS generally requires keeping cardholder data out of the AI processing path. Gateway redaction and access scoping can prevent the data from reaching the model.

FedRAMP

FedRAMP and equivalent programs constrain processing location. Workloads therefore need the portability required to use an approved placement.

The EU AI Act

The EU AI Act attaches obligations to outcomes and risk categories. Engineering teams need records that show what a system did and the basis for the action. An agent trace with an appropriate retention policy can provide that record.

The NIST AI Risk Management Framework

NIST AI RMF 1.0 is voluntary and organizes work around Govern, Map, Measure, and Manage. Within BROCS, Map and Measure relate to Observe, Manage to Control, and Govern to Secure. Teams using the RMF should identify where each function is implemented. NIST is revising AI RMF 1.0 in 2026, so use the linked issuer page for current status.

Continuous evidence

Evidence requests should be answerable from records over a specified date range without depending on an engineer's memory.

Treat each required record as a platform output:

• The inventory is generated from what is deployed, not maintained by hand.
• Access records come from shared ingress.
• Change records come from version control, because configuration lives there.
• Processing records come from traces with retention set by what they contain.
• Deletion is evidenced, not asserted.

These records also reduce the time required to investigate incidents and prepare audits.