EU AI Act, DORA & GDPR - compliance, engineered in
One structural answer to three regulations: classify first, then keep data and inference EU-sovereign and air-gapped-capable - so each obligation maps to evidence we deliver, not a promise we make.
The EU AI Act, DORA, and GDPR read as three separate rulebooks, but for most AI systems they share one underlying risk: dependency on US-hosted cloud and models you cannot inspect, contain, or keep inside the EU. Two decisions do most of the heavy lifting across all three. First, classification - write down the AI Act risk tier of each system, whether you fall in scope of DORA as a financial entity or an ICT third party, and the lawful basis for every stream of personal data; almost every downstream duty follows from getting that first call right and recording it. Second, sovereignty - keep data and inference on your own infrastructure or an EU-sovereign cloud (Mistral AI for inference, Qdrant for vector search, EU data residency), with a self-hosted, on-prem, or fully air-gapped option, no required US data transfer, and no CLOUD Act exposure. This page walks the three regimes in that light and then shows how we build the evidence into the system rather than bolting it on before an audit. This is not legal advice, and we are not your compliance authority: the accountability for classification, lawful basis, and regulatory filings stays with you and your counsel. It describes how we help you meet and prepare for these regulations as engineers, grounded in production delivery, not how to interpret them - for anything binding, and for confirming current phase-in dates, rely on the official texts (Regulation (EU) 2024/1689, Regulation (EU) 2022/2554, and the GDPR) or your own counsel.
Start with the classification, not the checklist
Before you touch a control, decide three things and write them down: the AI Act risk tier of each system you ship, whether you fall in scope of DORA as a financial entity or its ICT third party, and the lawful basis for every stream of personal data. Get these wrong and you either over-engineer minimal-risk tooling or, worse, under-govern something consequential. Classify up when in doubt, name a single accountable owner per system, and record the rationale beside the code so the decision survives the next release. That classification is yours to own; what follows is what each call then obliges, and how we make the supporting evidence a property of the build.
EU AI Act - risk tiers, and your duties as a deployer
Regulation (EU) 2024/1689 sorts AI systems into four tiers, and the higher the tier the heavier the duty: prohibited systems you do not build; high-risk systems (hiring, credit, education, critical infrastructure, and similar consequential domains) owe risk management, data governance, technical documentation, logging and traceability, human oversight, and accuracy and robustness; limited-risk systems owe transparency - tell users they are talking to AI and label synthetic content; minimal-risk carries no specific obligations. High-risk is defined mostly by use case and context, not by how clever the model is, so a simple classifier deciding who gets a loan outranks a powerful model summarising your own notes. The Act also separates the duties on providers of general-purpose models from the duties on you as a deployer building a product on top - most product teams are deployers, and Article 26 still obliges you to use the system per its instructions, assign competent human oversight with a real stop and override path, and keep the logs the system generates. Article 27 adds a separate duty for deployers - a fundamental rights impact assessment for public-body and certain high-risk uses. We map each duty to an artefact: pinned model and version provenance for the technical record; an immutable, append-only, per-tenant, database-enforced audit trail for the logging obligation; a built-in human-in-the-loop review gate for oversight; and AI-interaction and synthetic-content transparency notices where they apply. Keeping inference on EU-sovereign or air-gapped infrastructure removes the cross-border variable so the classification and evidence stay clean. The Act is being phased in over roughly 2024 to 2027, so confirm the current deadline for your tier against the official text rather than a marketing page.
DORA - ICT and third-party risk a financial entity can put in its register
The Digital Operational Resilience Act (Regulation (EU) 2022/2554) applies to banks, insurers, investment firms, and a wide set of other financial entities - plus the ICT third-party providers that serve them. It obliges an ICT risk-management framework, incident classification and reporting, resilience testing, and a register of information describing every ICT third-party dependency, with particular attention to concentration risk where too much critical service rides on one provider. A hard dependency on a single US hyperscaler for AI inference is exactly the concentration risk DORA asks you to identify and reduce. An EU-sovereign or self-hosted deployment - running inference and vector search inside the EU on Mistral AI and Qdrant, self-hosted or air-gapped, with no required US data transfer - removes that critical-provider dependency and the CLOUD Act exposure that comes with it, and keeps the ICT supply chain inside your control and jurisdiction. We are an ICT service provider you can assess and document, not a resilience guarantee: the resilience testing and register upkeep remain your programme. What we supply are the facts your register and testing depend on - where the system runs, what it depends on, the immutable per-tenant audit trail behind it, and the single-tenant or air-gapped option for the strongest isolation posture.
GDPR - the data layer under both
The AI Act governs the system and DORA governs operational resilience, but GDPR governs the personal data flowing through all of it, and if your AI touches personal data it applies in full and in parallel. Data residency, a signed DPA, a maintained ROPA, DSAR handling, and a DPIA for higher-risk processing are the load-bearing pieces - and you can reuse most of that work, since a GDPR DPIA and the AI Act's risk-management documentation cover much of the same ground when you write them to reference each other. Our EU-sovereign path keeps data and inference inside the EU by construction, so you are not reasoning about cross-border transfers on top of everything else, and PII redaction runs before the model sees the data, narrowing what is ever processed. Retrieval is the common trap: indexing a document does not grant a new lawful basis to surface it, so data minimisation, purpose limitation, and defensible log retention have to be designed in, not patched later - and we scope access per tenant with PostgreSQL Row-Level Security plus per-tenant vector collections so that boundary is enforceable rather than assumed. The lawful basis stays yours to establish; we build the controls that make it hold.
How TechRevati helps - one deployment, evidence for all three regimes
The EU AI Act governs the system, DORA governs the operational resilience of the financial entity running it, and GDPR governs the personal data flowing through - but they overlap heavily, and most of the evidence is shared. We start from the Sovereign RAG Pilot: a fixed-scope, single-tenant deployment on your infrastructure or an EU-sovereign cloud (Mistral AI inference, Qdrant vector search, EU residency, self-host or air-gapped), wired to one real use case, whose properties satisfy duties across all three regimes - an immutable, append-only, per-tenant, database-enforced audit trail for logging and traceability; pinned model and version provenance for the technical record and your register; PII redaction before the model sees data for GDPR minimisation; a human-in-the-loop stop and override path for Article 26; and access scoped with PostgreSQL Row-Level Security plus per-tenant vector collections, with single-tenant or fully air-gapped for the strongest assurance. To be plain about our own posture: our controls are mapped to SOC 2 and ISO 27001 evidence and we can walk you through that mapping, but attestation is on our roadmap and not yet held - we will not claim certifications we do not hold, and for healthcare we deliver HIPAA-ready architecture rather than a HIPAA certification. The proof is delivery: AI Nexus ITSM runs on-prem, zero-egress ServiceNow incident analysis, and Ollama-ServiceNow Defender is a fully-local ServiceNow app - both examples of the sovereign, no-egress posture this page describes, and both designed so the compliance evidence is a property of the system rather than a scramble before launch.
FAQ
Does the EU AI Act, DORA, or GDPR content here count as legal advice?
No. Everything on this page is engineering guidance on how we help you meet and prepare for these regulations, grounded in production delivery. It is not legal advice and not a guarantee of compliance, and we are not your compliance authority - the accountability for risk classification, lawful basis, regulatory filings, and register upkeep stays with you and your counsel. Regulatory timelines and scope shift, so confirm the specifics for your tier and entity against the official texts (Regulation (EU) 2024/1689, Regulation (EU) 2022/2554, and the GDPR) or your own counsel before relying on any of it.
We are a financial entity under DORA - how does an EU-sovereign deployment help our ICT third-party risk register?
DORA (Regulation (EU) 2022/2554) requires you to identify, manage, and document ICT third-party risk, including concentration risk where one critical provider carries too much load. A hard dependency on a single US hyperscaler for AI inference is precisely that kind of concentration risk. Running inference and vector search on an EU-sovereign stack (Mistral AI plus Qdrant, EU data residency), self-hosted or air-gapped with no required US data transfer and no CLOUD Act exposure, reduces that dependence and keeps the ICT supply chain inside your jurisdiction - and it gives you concrete facts to record in your register of information: where the system runs, what it depends on, and the immutable per-tenant audit trail behind it. We are an ICT service provider you can assess and document; the resilience testing and register upkeep remain your programme, and we supply the deployment facts to complete it.
Do you hold SOC 2, ISO 27001, or HIPAA certification?
No, and we will not claim certifications we do not hold. Our controls are mapped to SOC 2 and ISO 27001 evidence and we will walk you through that mapping, but formal attestation is on our roadmap and not yet held. For healthcare workloads we deliver HIPAA-ready architecture rather than a HIPAA certification. If a certification is a hard requirement for your procurement, we will tell you plainly where we stand rather than paper over it - and what we deliver today is provable: an immutable, append-only, per-tenant, database-enforced audit trail and the option of single-tenant or fully air-gapped deployment for the strongest isolation assurance.
Am I the provider or the deployer under the EU AI Act, and does calling a third-party model via API let me off the hook?
For most teams building a product on top of a general-purpose model, you are the deployer, not the model's provider, and using it via API does not remove your duties. Deployer obligations under Article 26 include competent human oversight with a real stop and override path, keeping the logs the system generates, transparency to affected people (a fundamental rights impact assessment is a separate Article 27 duty for certain uses); the provider duties on the base model sit with whoever supplies it. We pin the model and version you depend on and capture the operational evidence behind those duties by default. If you substantially fine-tune or rebrand a base model as your own, provider duties may begin to attach to you, which is worth re-checking with counsel - and the risk classification and the decision to deploy stay yours.
Is our AI chatbot high-risk under the EU AI Act?
Usually not by default. A customer-support or assistant chatbot typically falls under limited-risk transparency rules, which means you must tell users they are interacting with AI and label AI-generated content. It only becomes high-risk when it is used in a consequential domain the Act lists - for example materially influencing hiring, credit, or safety decisions - so the classification depends on the use case and context, not on the model's capability. When in doubt, classify up and record the rationale.
Do we have to move everything to Europe, or can we keep some US-hosted models?
You choose deliberately per workload. Many workloads run perfectly well on US-hosted models, and we support that - the point is that the choice is intentional and the audit trail is intact either way. Where the AI Act, DORA, or GDPR make cross-border processing a real liability, the EU-sovereign or air-gapped path (Mistral AI plus Qdrant, EU data residency) removes the cross-border variable entirely, with no required US data transfer and no CLOUD Act exposure. A Sovereign RAG Pilot lets you prove the sovereign path against one real use case before committing.
See sovereignty proven, not promised - start a Sovereign RAG Pilot
Bring one real use case and we will stand up a fixed-scope, single-tenant Sovereign RAG Pilot in your own environment or on an EU-sovereign cloud - Mistral AI and Qdrant, EU data residency, self-hosted or air-gapped - with the compliance evidence built in: classified by risk tier, PII redacted before the model sees data, an immutable, append-only, per-tenant, database-enforced audit trail, a human-in-the-loop stop and override path, and access scoped with PostgreSQL Row-Level Security plus per-tenant vector collections. You will see how classification-first, sovereign-by-design engineering makes the AI Act, DORA, and GDPR obligations properties of the system rather than paperwork before an audit - and we will scope it with you. Start a pilot.