AI Compliance Is Not Just About GDPR

GDPR is the floor of AI compliance, not the ceiling. An organisation can be word-perfect on data protection and still unable to answer the question every other regime asks: what did the system do, on what basis, and who authorised it before it happened. That question sits underneath the EU AI Act, NIS2, DORA, ISO 42001, ISO 27001, SOC 2 and a firm's own delegated authority matrix. Scoping AI compliance as a data protection exercise is the most expensive mis-scoping in the boardroom.

Why does GDPR only cover part of the exposure?

GDPR governs personal data. Article 22 does bite on automated decisions producing legal or similarly significant effects on a person. But its subject is the data, its lawful basis, and the rights of the individual it describes. It says little about a system that decides nothing about an identified person and still creates severe exposure: a model that misprices risk in an underwriting book, an agent that reconfigures production infrastructure at 02:00, an automation that alters a payment run and is caught only at reconciliation.

Anonymise everything and GDPR recedes. The operational, prudential and reputational risk does not move a single point. Boards discover this late, because data protection has an owner and a budget line, and the AI system has neither.

What does the wider regulatory surface actually look like?

Not one regime with an AI chapter bolted on. A stack of overlapping evidentiary duties, each with a different reader, a different clock and a different retention period.

• EU AI Act: risk classification, technical documentation, human oversight and record keeping. The timetable is phased and has been amended. The engineering requirement does not change with the date. Only the deadline does.
• NIS2: cybersecurity risk management, accountability escalated to senior management, and incident reporting on a statutory clock.
• DORA: ICT risk management, a register of third party arrangements, incident classification and resilience testing for EU financial entities.
• Sector supervision: conduct, medical device, energy, aviation and defence authorities impose their own reconstruction duties. None disapply because a model was in the loop.
• ISO 42001, ISO 27001 and SOC 2: the auditor wants records, not intentions, and tests a population of events, not a comfortable selection.
• Internal policy: the delegated authority matrix and the risk appetite statement. Often the strictest instrument in the building, and the first quietly waived to get a pilot live.

Is there a single obligation underneath all of them?

Yes. Not "have a policy". It is: prove what the system did. Each regime is a different reader asking one variant of that question. The regulator says reconstruct this decision. The auditor says show me every event, not the sample you like. Counsel says show me the record was not written after the letter arrived. The insurer says show me the authority existed before the act.

What varies is the reader, the clock and the retention. What does not vary is the noun. Every one terminates in the record. By the time this reaches the board it is an architecture question, answered silently at build time.

Why doesn't ordinary logging satisfy this?

Because a conventional log is a byproduct, not evidence. It fails three tests. First, it is descriptive: it records what the application chose to emit, not what was authorised, by whom, under what clearance. Second, it is mutable: written after the act into a store a privileged credential can rewrite, so it is only ever an assertion about the past. Third, it is not independently verifiable: proving it to a hostile reader means asking that reader to trust the system that produced it. That is not a chain of custody. It is a chain of assurances.

So we seal the record of a consequential action before it executes, sign it with post-quantum FIPS 204 ML-DSA-65, and hash-chain it so any later edit is detectable. The Open Audit Record is verified offline, by a regulator or a court, using neither our infrastructure nor our goodwill. The point is not better logging. It is moving the record from assertion to evidence.

What is the honest counter-argument?

That this is over-engineering, and for most workloads it plainly is. Most enterprise AI is not consequential: a draft, a code suggestion, a summary. Nobody needs cryptographic sealing for a first draft, and for that class the hyperscale platforms are the right answer. Our claim is confined to the consequential class: actions that move money, grant or deny entitlement, change access, or alter operational state. The stronger objection is that no regime demands cryptographic proof by name. True. They demand that you demonstrate, and the cost of demonstration falls not on the day you build but on the day you are asked, under a statutory clock, about a system three versions and two vendors ago. Evidence cannot be retrofitted.

What should the board ask on Monday?

• Which AI systems can we reconstruct a single decision from, end to end, without asking a vendor for help?
• For any consequential action, can we show the authority existed before the act rather than after it?
• Whose clock is shortest across the regimes that bind us, and have we rehearsed against it?
• What have we quietly waived from our own authority matrix to get AI into production?

If most of those have no clean answer, the exposure was never GDPR. GDPR is simply the only part of it that already had a named owner.

Frequently asked questions

Does GDPR compliance mean we are EU AI Act compliant?

No. GDPR governs the processing of personal data and the rights of the person it describes. The AI Act governs the system: how it is classified by risk, documented, overseen by humans and recorded. A system handling no personal data at all can sit inside one and outside the other. Running them as one programme is a scoping error that surfaces during an inspection.

Does the EU AI Act reach us if we are not established in the EU?

Possibly, yes. The Act is drafted with extraterritorial reach and can capture organisations established outside the Union where the system is placed on the Union market or its output is used there. Non-EU organisations serving EU customers should test scope rather than assume exemption, and take that analysis from counsel, not a vendor's compliance page.

Is ISO 42001 certification enough on its own?

No. ISO 42001 certifies that a management system exists and is operating, which is valuable and worth doing. It does not, by itself, let you reconstruct what a specific model did on a specific Tuesday for a specific claimant. Certification proves process, and regulators, courts and insurers escalate from process to instance. That is where undocumented systems fail.

How quickly should our evidence be available after an AI-involved incident?

Immediately, because reporting clocks start at the incident and are not extended while you assemble a story. Notification duties run from the moment something becomes significant, not from the moment a vendor answers your support ticket. If the record exists only in application logs and third party queues, assembly is a project and the deadline lands mid-project.

Mickai is a British Sovereign Intelligence Operating System, built and live, running offline on hardware the organisation owns and inside its own jurisdiction. Every consequential action is sealed in the Open Audit Record before it executes, signed with post-quantum FIPS 204 ML-DSA-65, hash-chained, and verifiable offline by a regulator or a court. The architecture is protected by 104 filed UK patent applications carrying 2,340 claims, owned by Mickai LTD. For the evidentiary layer, read /oar. For the architecture, read /sovereign-ai. To map your surface against the regimes that bind you, start at /ai-readiness.