How are engineering teams handling AI compliance? | Hacker News Reader

How are engineering teams handling AI compliance?

2 pointspartycat2 comments

Companies are adopting AI tools fast, but I keep wondering about the human side of it — not whether the tools work, but whether engineers actually know what they're and aren't allowed to do with them.

Specific things I'm curious about: does your company have real AI usage policy or is it "use common sense"? Has anything gone wrong — data sent somewhere it shouldn't, AI used in an auditable decision with no trail? And if someone asked you today whether your team is compliant with AI Act or SOC2 in how they use AI — could you actually answer that?

View on HN

The "use common sense" policy is basically no policy, and it tends to get companies into trouble exactly when they need documentation most — during a SOC2 audit or an incident investigation. The specific gap I see most often isn't engineers using AI wrong, it's that there's no way to reconstruct what data went to which model when, so if a customer asks "did my PII go to OpenAI?" you're stuck guessing.

The AI Act angle is trickier than SOC2 because it depends heavily on what the AI is actually doing. Are engineers using it for internal tooling or in anything customer-facing that influences a decision? Most teams I've talked to genuinely don't know where their usage falls on that spectrum, and that uncertainty is exactly what auditors poke at.

What's the split in your context between AI for internal dev productivity vs. AI that touches actual product or customer workflows? That changes what "compliance" even means here.

The gap matrixgard identifies — not knowing what data went to which model when — is exactly what Article 12 of the AI Act tries to close. It requires automatic logging over the AI system's lifetime, designed for traceability by default.

In practice, I've seen three levels of "handling it":

1. Nothing. Most teams. "We use GPT through the API" with zero audit trail of what was sent or returned. If a customer asks under GDPR Article 15 what personal data was processed by an AI system, they can't answer.

2. Application-level logging. Better. But logs are operator-controlled — you can edit or delete entries. An auditor has no way to verify completeness. This is where most teams who "take compliance seriously" actually land.

3. Tamper-evident logging with hash-chaining. Each log entry includes a hash of the previous entry, so deleting or reordering anything breaks the chain. This is what the regulation seems to actually require when it says records should enable "automatic recording" and "traceability." Almost nobody does this yet.

The SOC2 angle is simpler as it has already has defined controls for access logging. The AI Act angle is harder because the technical standards (harmonised standards under Article 40) aren't published yet. So currently, you're building against the text of the regulation itself, which is 144 pages of cross-references.

Most honest answer I've seen: teams that will deploy AI in customer-facing workflows and can't reconstruct what happened are carrying regulatory risk they haven't quantified yet.

Reply on news.ycombinator.com