A regulator does not care that you have a policy describing how personal data is handled. A regulator cares whether your systems handle it that way, and whether you can prove they do.
That is the gap. The compliance industry has spent two decades closing it with paperwork. PDFs of policies. Spreadsheets of controls. Year-plans of attestation tasks. Annual external audits that certify what was true on a single day. Underneath it all, the actual systems keep changing and the documents quietly fall out of date.
The EU regulatory stack ends that approach. GDPR’s Article 32, the AI Act’s Article 15, and the EU Data Act’s access constraints all describe properties the running system must exhibit. They do not describe documents the system must produce. A document can be evidence of compliance. A document cannot be compliance.
Today we are introducing Sakura Sky’s Governance, Risk & Compliance service, built on that observation. GRC is not a fourth discipline alongside Cloud, Data, and Security; it is the outcome of those three being engineered correctly. Our GRC service draws on all three practices and lands the substrate that regulators want to see. Inside it lives Praxis, our productised compliance solution. Where Sentinel watches and Enclave isolates, Praxis verifies.
The Template Era is Ending
For most of the last decade, compliance has been a documentation problem. Pick a framework. Buy a portal that ships with the right templates. Fill in the templates. Hire consultants to fill them in faster. Hand the result to an auditor. Repeat next year.
This worked for two reasons. First, regulators were primarily interested in whether the organisation could describe its controls coherently. Second, the cost of verifying that the description matched reality was prohibitive, so verification happened rarely and at high expense.
Neither condition still holds. Supervisory authorities under GDPR have been asking for evidence of running controls, not policies describing them, since at least 2019. The AI Act explicitly demands logged execution evidence under Article 12 and ongoing post-market monitoring under Article 72. The EU Data Act expects access constraints to be enforced in code, not described in T&Cs. And the cost of verification has collapsed. A modern observability stack already generates more attestation-grade evidence per hour than a Big Four auditor produces in a quarter.
The template era assumed documents were the artefact and reality was the audit. The next era assumes reality is the artefact and documents are a derived view of it.
What Engineered Compliance Actually Means
Engineered compliance has three properties.
It treats every obligation as a property of the running system. Article 32’s encryption requirement is not a checkbox in a security policy; it is a configuration in a key management service that can be queried and verified. An AI Act Article 15 robustness requirement is not a paragraph in a model card; it is a set of adversarial tests that run in CI and whose results are signed and stored. A Data Act access constraint is not a clause in a data sharing agreement; it is a policy enforced at runtime by a gateway that logs every access attempt.
It produces evidence as a continuous side effect, not as a periodic exercise. If your CI pipeline already runs robustness tests, the evidence the AI Act wants already exists. If your platform already emits structured access logs, the evidence the Data Act wants already exists. The work is not to generate evidence; the work is to format and address it so a regulator will accept it on its first request.
It treats the regulatory text and the system as a paired corpus. The regulation is a specification. The system is the implementation. When either changes, the other has to be re-verified. That is an engineering problem, not a legal one, and it benefits from the same toolchain engineers already use to keep code aligned with specs.
This is not a new idea in security. SOC 2 and ISO 27001 have been edging toward continuous compliance for years. The EU regulatory stack pushes the same model into data protection, AI, and data sharing simultaneously, with statutory penalties attached.
The Praxis Compliance Agent
At the centre of Praxis is a domain agent we build and operate on your behalf. We load it with two corpora.
The first is regulatory. The agent has the live text of GDPR, the AI Act, and the EU Data Act, including recitals, official guidance from the EDPB and ENISA, supervisory authority opinions, and authoritative academic and industry interpretations. When any of those change, the agent registers the change.
The second is yours. The agent ingests your policies, your DPIAs, your ROPA, your model cards and system cards, your data flow diagrams, your relevant code repositories, and the outputs of your existing Sentinel and Enclave deployments. With your permission, it can also pull from your observability pipelines, your CI evidence, and your access logs.
We then use the agent inside our delivery to produce three outputs. A mapped gap analysis showing where your current state diverges from the applicable obligations. A prioritised remediation plan in concrete engineering tasks, not policies to write. And, in continuous engagements, an ongoing readiness score per framework that updates with every system change and every regulatory update.
This is different from a general-purpose compliance chatbot in one specific way. A chatbot trained on regulation text can tell you what the law says. The Praxis agent, run inside our engagement, helps us tell you whether your systems align with it, and what to change if they do not. The first is a reference book. The second is a verification workflow.
The agent does not replace your legal team or your DPO. It removes the parts of their job a machine should be doing, so they can focus on the judgement calls that only humans should be making. The classification of a borderline processing activity, the negotiation with a supervisory authority, the framing of a privacy-by-design trade-off for the board. Those decisions need lawyers. Tracking which of your 800 microservices logs IP addresses and whether each one has an Article 6 lawful basis assigned does not.
How We Deliver It
Praxis runs in three engagement shapes, each calibrated to where your platform actually is on its regulatory journey. The thread across all of them is the same: compliance engineered into the running system, evidence produced as a side effect of operating it, and a posture that is defensible the day a regulator asks.
The roadmap engagement is the front door. We scope the regulatory surface that applies to your systems, run an initial gap analysis, and produce a prioritised remediation plan with engineering effort estimates. Most organisations have never seen this level of specificity. A roadmap engagement typically runs a few weeks and produces a document your CTO and your General Counsel can both sign.
The delivery engagement implements the plan. Sentinel deployment for AI and policy governance. Enclave deployment for the workloads that need it. The Praxis agent stood up inside our engagement with your corpus loaded. Evidence pipelines wired into your existing observability stack. Cross-framework control mapping documented and tested. This is months of work, scaled to the surface area.
The continuous engagement runs the agent against your platform on an ongoing basis and provides regulator liaison support when needed. Every deployment, every policy change, every model update triggers re-verification. Drift surfaces immediately. Quarterly evidence packs go to your audit committee or your supervisory authority on request. Annual external review is supported but not driven by a year-end scramble.
On the Clock
Three deadlines drive the urgency. The AI Act’s high-risk obligations begin to bite from August 2027, and the conformity assessment work to get there is measured in quarters, not weeks. The EU Data Act applies from September 2025 onwards, with progressively tightening obligations through 2027. And GDPR enforcement continues to escalate, with supervisory authorities increasingly asking for technical evidence and decreasingly satisfied with policy documents alone.
For crypto-asset firms, MiCA adds a fourth pressure point: Title III obligations for asset-referenced and e-money tokens have applied since mid-2024, and CASP licensing under Title V has been live since December that year, with transitional grandfathering tapering through mid-2026. We are increasingly engaged in this space and treat MiCA with the same engineered-compliance approach as the broader EU regulatory stack.
Organisations that approach this as three separate compliance projects, each driven by templates, will spend three times what they need to and end up with three sets of artefacts that contradict each other in the first audit. Organisations that approach it as one engineered substrate, designed once and evidenced continuously, will spend less and defend better.
We have written extensively about the technical and legal mechanics of the EU regulatory stack in our Regulatory Stack series. Part 3 maps the Triad of Liability under the AI Act. Part 4 covers the engineering substrate that makes Article 15 a deployment side effect rather than a compliance project. Praxis is how that thinking arrives at your platform.
If your organisation is approaching the EU regulatory stack and you are looking at it as a documentation problem, we would like a conversation. The longer you wait, the more expensive the substrate is to retrofit.
Talk to us about a roadmap engagement.
This article describes Sakura Sky’s Governance, Risk & Compliance service and the Praxis solution within it. It is not legal advice. Specific obligations under GDPR, the EU AI Act, the EU Data Act, and MiCA depend on the nature of your systems, the data and assets you process, and your role under each regulation. Consult qualified counsel before relying on any of the implementation patterns described above for compliance with a specific framework.