Research · AI governance
EU AI Act for enterprise: European data, inference and sovereign AI deployments
AI-generated visualPutting AI into production takes more than choosing where the model runs. It requires clear accountability, verifiable controls and an architecture aligned with actual risk.
The AI Act is a risk-based regulation. It considers a system’s intended purpose, the people it may affect and the role played by each organisation. Providers, deployers, importers and distributors do not carry the same responsibilities. The first question is therefore not “cloud or on-premise?”, but “what system are we using, for what purpose and under whose responsibility?”.
The essential point
Keeping data and inference in Europe can strengthen control, security and operational sovereignty, but it does not make a system automatically AI Act compliant. Compliance depends on role, intended purpose, risk and lifecycle controls.
The timeline enterprises need in 2026
The regulation entered into force on 1 August 2024 and became generally applicable on 2 August 2026, with exceptions and phased dates. Prohibitions and the first AI literacy provisions have applied since 2 February 2025; general-purpose AI obligations since 2 August 2025. Following the AI Omnibus that entered into force on 27 July 2026, the current dates for high-risk systems are 2 December 2027 for Annex III use cases and 2 August 2028 for high-risk systems embedded in Annex I regulated products.
Official references: the European Commission’s AI Act overview and AI Omnibus update.
1. Start with inventory, role and intended purpose
A useful AI inventory is not a subscription list. For each system it should record ownership, intended purpose, users, affected people, data and sources, model or vendor, enabled actions, runtime environment and human oversight.
- Classify the role. An enterprise may be a deployer of a third-party system, provider of its own solution, or take on new duties after a substantial modification.
- Classify the risk. Not every AI system is high-risk; classification follows intended use and context, not the technology alone.
- Set boundaries. Define what the system may read, decide or execute, when it must stop and who owns the outcome.
2. European data and inference: why they matter
Processing data and inference in Europe can reduce transfers, make the subprocessor chain clearer, and support contractual, security and data-governance requirements. For regulated organisations, it may also be a procurement or internal-policy requirement.
This matters, but it is distinct from regulatory compliance. A system that runs entirely in Europe can still lack adequate documentation, oversight, logging or monitoring. Conversely, the AI Act does not impose a general requirement that every inference happen in the EU; additional duties may follow from GDPR, the Data Act, sector rules, contracts and internal policies.
3. Choose deployment around actual risk
European cloud
For enterprise workloads needing European processing, scalability and managed services, with regions, subprocessors and data flows documented.
Private cloud / VPC
For network isolation, controlled access and narrower data paths while retaining some managed operations.
On-premise
For keeping data, models and observability inside the organisation’s infrastructure when security or confidentiality requires it.
Air-gapped
For scenarios requiring separation from public networks. Maximum isolation, with a higher operational burden for updates, monitoring and security.
Sovereignty without slogans
“Sovereign” should describe verifiable controls: data location and access, portability, technical dependencies, keys, network, logging, continuity and the ability to change provider. It is not a regulatory shortcut.
4. The control plane around the architecture
- Data governance: provenance, quality, usage rights, minimisation, access and retention.
- Evaluations: accuracy, robustness, security, relevant bias and out-of-scope behaviour.
- Transparency: understandable information for users and disclosure where people interact with AI or encounter synthetic content in applicable cases.
- Human oversight: competent people, real authority to intervene, escalation paths and the ability to suspend automation.
- Observability: logs, versions, metrics, sources, feedback and incidents. For certain deployers of high-risk systems, Article 26 requires logs under their control to be kept for at least six months unless other applicable law provides otherwise.
- Change management: assess every model, data, prompt, tool or purpose change before release.
- AI literacy: proportionate training for the people building, governing and using systems.
See the official Regulation (EU) 2024/1689, the Service Desk page on deployer obligations under Article 26, and the Commission’s Article 50 transparency FAQ.
5. A practical first 30 days
- 01Inventory
Map systems, owners, intended purpose, data, vendors, users and affected people.
- 02Classify
Determine role, risk category, sector rules and documentation gaps.
- 03Prioritise
Address systems affecting people, sensitive data or real-world actions first.
- 04Evidence
Connect every control to proof: tests, logs, decisions, approvals and incidents.
How Hoplo approaches the work
We design vertical agents around the real job: grounded sources, least privilege, human approvals, audit trails and monitoring. Depending on the use case, we can design European cloud, private, on-premise or air-gapped architectures. The deployment decision is documented alongside operational controls, without claiming automatic compliance.
Legal note. This content is general information and is not legal advice, a conformity assessment or a certification. Applicable obligations depend on the system, intended purpose, the organisation’s role, risk category and other applicable laws. The Commission’s official AI Act Compliance Checker can support an initial self-assessment and is itself informational.