Security, governance and compliance
For organizations with high security requirements — public bodies, banks, insurers, regulated industry — security isn’t a separate chapter: it’s a design constraint from the very first line of architecture.
In short, three promises
Your data stays under control
Classification, minimization, segregation between clients, and no training on your data without explicit authorization — on cloud, on-premise or hybrid infrastructure, matched to your constraints.
AI doesn't act beyond defined limits
High-impact actions remain subject to explicit human confirmation; any content retrieved from external sources is treated as untrusted input, never as an instruction.
Every relevant decision is verifiable
Sources, actions and assisted decisions stay tracked with a reference to the originating data, with roles and responsibilities defined from the system's design stage onward.
The detail, for whoever has to verify it
Data governance
Classification of the data processed, minimization, no training on client data without explicit authorization, segregation between environments and clients.
On-premise, cloud & hybrid
Deployment follows the organization’s constraints, not the other way around: when data residency is non-negotiable, the architecture stays on-premise or hybrid.
Audit trail
Every source consulted, action taken and assisted decision is logged in a verifiable way, with reference to the originating data.
Human-in-the-loop
High-impact actions remain subject to explicit human confirmation; the system flags uncertain cases instead of deciding on behalf of people.
Prompt injection defense
Every piece of content retrieved from documents, emails or external pages is treated as untrusted input: system-prompt isolation, sanitization, control over the actions agents can execute.
AI Act
Risk classification of the system, technical documentation and transparency requirements aligned with the European regulatory framework, handled from the design phase onward.
Roles & responsibilities
Explicit definition of who can configure, supervise, approve or disable the system, and who is accountable for each stage of its operation.
Logging & traceability
Technical and application logs retained according to agreed policies, usable for internal audits, external reviews and incident analysis.
Certification and compliance roadmap
The AI Act, in brief
The EU’s AI Regulation applies in phases. From 2 August 2026, the Article 50 transparency obligations apply, along with full supervision and penalty powers; the July 2026 Digital Omnibus, however, deferred the obligations for high-risk systems. For banks, insurers and public bodies, this isn’t a topic to postpone: the deferral concerns the deadlines, not the preparation needed to meet them.
1 Aug 2024
Regulation enters into force
2 Feb 2025
Ban on unacceptable-risk practices
2 Aug 2025
GPAI model obligations and governance rules
27 Jul 2026
Digital Omnibus in force: high-risk system obligations deferred
2 Aug 2026
Transparency obligations (Art. 50) and full supervision and penalty powers
2 Dec 2027
High-risk system obligations apply (Annex III)
2 Aug 2028
Obligations for AI in regulated products (Annex I)
2 Aug 2030
Extended deadline for part of the high-risk systems already in use by public authorities
Risk classification
The Regulation distinguishes four tiers: unacceptable risk (banned), high risk (strict obligations), limited risk (transparency obligations) and minimal risk. The tier depends on how the system is used, not on the technology itself.
Who is most directly affected
Credit scoring, insurance risk assessment, workforce management and access to essential public services fall under the Annex III high-risk use cases: banks, insurers and public bodies are among those most exposed.
Obligations for high-risk systems
Risk management system, data governance, technical documentation, automated logging, human oversight and conformity assessment before going into production.
Deployers, not just providers
Anyone using a high-risk system — not just those who build it — has obligations of their own: public bodies and specific financial-sector cases must carry out a fundamental rights impact assessment.
The AI Act’s four risk classes
The level of obligation depends on how a system is used, not on the underlying technology: the same model can fall into different classes depending on the context it's deployed in.
We treat these obligations as an architectural constraint from day one, not as paperwork added at the end of a project: risk classification is the first step of every AI Assessment.
Read Regulation (EU) 2024/1689 on EUR-LexHow we validate a system before release
Security testing is part of the project, not a final checkbox.
- 01
Threat modeling
We identify the abuse scenarios most relevant to that specific process: exposed data, unauthorized actions, prompt injection.
- 02
Red teaming
Targeted attempts to bypass guardrails, manipulate the system prompt, or obtain data and actions that were never intended.
- 03
Testing on real cases
Verifying accuracy and behavior on real data and scenarios, not just on prepared examples.
- 04
Permission review
Cross-checking roles, access and data segregation before releasing to production.
This page does not replace a formal compliance assessment specific to your sector: it’s the foundation we build on, together with your security, governance and data protection teams, to deliver a system that is ready for production.
Request an AI AssessmentFrequently asked questions
How does Futura AI secure its AI systems?
Application guardrails, prompt injection defense, a full audit trail, and human confirmation on high-impact actions.
With application guardrails, prompt injection defense, audit trails on every source and assisted decision, and human-in-the-loop on high-impact actions. Testing includes threat modeling and red teaming before release to production, not after: a system goes into production only once accuracy, robustness and traceability have been verified on realistic cases, and high-impact actions still require human confirmation.
Are Futura AI’s systems AI Act compliant?
Yes: risk classification is the first step of every Assessment, not paperwork added at the end of the project.
We treat the obligations of Regulation (EU) 2024/1689 as an architectural constraint from day one: risk classification of the system is the first step of every AI Assessment, not paperwork added at the end of the project. The ban on unacceptable-risk practices has been in force since 2 February 2025. From 2 August 2026, the Article 50 transparency obligations apply, along with full supervision and penalty powers; the July 2026 Digital Omnibus, however, pushed back the obligations for Annex III high-risk systems to 2 December 2027, and to 2 August 2028 for Annex I. In practice, this means technical documentation, decision traceability and impact assessment are built into the architecture, not reconstructed after the fact once a system is already in production: it's simpler to design them in from the start than to bolt them on later — and the deadline extension is no reason to delay that work, just more time to do it properly. It's the standard we apply from the very first analysis of a process.
Does Futura AI train models on client data?
No: no training on client data without explicit authorization, in environments separated per client.
No. Data governance includes classification, minimization and segregation between environments and clients: no training on client data without explicit authorization. Each client works in a separate environment, with permissions aligned to the roles and policies already in place in the organization, and the data used to query the system — documents, archives, business systems — stays distinct from any data used to evaluate or improve the system itself. When a project requires fine-tuning or model customization, that choice is agreed explicitly with the client as part of the architecture, not applied by default: the rule is that the system's behavior in production depends on configuration, prompt engineering and data retrieved in real time, not on quietly training on the organization's confidential information. This applies equally to public and private clients, with no exceptions based on sector or project size.
Does Futura AI hold security certifications?
We design according to technical and organizational measures aligned with GDPR; ISO 9001, ISO 27001 and NIS2 certifications are in progress.
The certification roadmap is in progress: ISO 9001 (quality management) and ISO 27001 (information security) are in the certification process, alignment with the NIS2 cybersecurity directive is underway. On GDPR we don't claim a general "compliance" — it doesn't exist as such, it's specific to each processing activity — but we design and configure systems according to technical and organizational measures aligned with the applicable obligations: minimization, segregation, access management, traceability, and contractual definition of controller/processor roles. The compliance assessment stays specific to each processing activity and is carried out with the client and, when needed, with their privacy contacts. We'd rather state the roadmap's real status than present an unfinished milestone as already achieved: for regulated organizations such as public administration, banks and insurers, independent verification matters more than the announcement. In the meantime, the security controls the ISO/NIS2 certifications formalize — data governance, access management, decision traceability, incident management — are already built into how we design and test every system, regardless of certificate status, because they are architectural requirements, not just documentation requirements. The progress of each certification is listed on the dedicated security and governance page, and we update it as each milestone is actually reached rather than in advance.