S ยท Secure

Compliance

HIPAA, SOC 2, PCI, FedRAMP, and the EU AI Act: audit evidence as a platform output rather than a quarterly scramble.

View as Markdown

Compliance is where the rest of the surface gets examined by somebody who was not in the room when it was built. The BROCS position is narrow and practical: your platform should produce audit evidence as a byproduct of running, rather than as a project that starts when an auditor sends a request list.

The scramble, and why it recurs

The pattern is familiar. An audit is scheduled. Someone assembles a list of AI systems by asking around. For each one, engineers reconstruct who had access, what data it touched, and which approvals applied, from logs that were not designed for the question. It takes weeks, the evidence is partial, and the same exercise repeats next year because nothing changed except that everyone is more tired.

The scramble is not caused by weak controls. It is caused by controls whose operation is not observable. A control that runs and leaves no record is indistinguishable, to an auditor, from one that does not run.

What evidence actually gets asked for

Across most frameworks the requests reduce to a small set:

  • An inventory. Which AI systems exist, what they do, what data they process, who owns them. This is the request that most often cannot be answered, and it is a Build and Control problem, not a compliance one.
  • Access records. Who could reach the system and its data during the period, and who actually did. From ingress and identity.
  • Change records. What changed, when, who approved it. From configuration.
  • Processing records. What the system did on behalf of whom. From traces.
  • Retention and disposal. What is kept, for how long, and proof that deletion happened. From storage.
  • Third-party posture. Which providers process your data, under what terms.

Every one of those is produced by a letter of the surface. If the letters are covered, the audit is a query. If they are not, the audit is archaeology.

SOC 2 is about whether your stated controls operate. AI systems are in scope when they touch systems in scope, which is more often than teams assume. The recurring finding is the inventory: AI tools adopted outside the normal path do not appear in the system description.

HIPAA turns on whether protected health information reaches the model. If it does, the endpoint needs to be covered by a Business Associate Agreement, and whether a given endpoint is covered has to be enforced by routing rather than documented in a policy.

PCI DSS is mostly about keeping cardholder data out of the AI path entirely. The practical control is redaction at the gateway plus scoping so the data is not reachable.

FedRAMP and equivalents constrain where processing happens, which makes portability a gating requirement rather than a preference.

The EU AI Act attaches obligations to outcomes and risk categories. The operational consequence for most engineering teams is record-keeping: being able to show what a system did, on what basis, without a person reconstructing it. That is the agent trace with a retention policy attached.

The NIST AI Risk Management Framework is voluntary and organizes around Govern, Map, Measure, and Manage. It maps onto the surface cleanly: Map and Measure are Observe, Manage is Control, Govern is Secure. If you are already running the RMF, BROCS is the question of where each function is implemented in your stack.

Continuous evidence

The target is that any of the requests above can be answered by running a query over a date range, without asking an engineer to remember anything.

Getting there is mostly about deciding, once, that the record is a deliverable of the platform rather than a side effect of logging. Practically:

  • The inventory is generated from what is deployed, not maintained by hand.
  • Access records come from one ingress rather than five.
  • 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.

That work is not free. It is considerably cheaper than the annual scramble, and unlike the scramble it also makes incidents shorter.

Questions to ask your vendor, or your own team

  • Can you produce a current inventory of AI systems, generated rather than maintained?
  • For a date range last quarter, can you show who accessed an AI application?
  • Can you show what changed in a prompt, when, and who approved it?
  • Where PHI or cardholder data is involved, what enforces the endpoint restriction?
  • Can you evidence deletion, or only assert it?
  • How many person-weeks did your last audit cost, and which of the questions above caused most of it?