Security & Delivery Pack

Operating model and accountability

Every project has a Futura AI lead you can name, who follows the system from the Assessment through to production and stays available after go-live. Roles and responsibilities — who configures, who supervises, who approves, who can disable the system — are defined explicitly with the client during the Assessment, not left implicit. Vertical specialists are brought in on the specific project when specific expertise is needed, not as a fixed structure added by default.

Data residency and segregation

Deployment — cloud, on-premise or hybrid — follows the client's constraints, not a default technology preference. In every configuration, each client's data and requests stay in an environment separate from other clients', and are not used to train the base models without explicit authorization.

Data and model ownership

Data uploaded by the client remains the client's property: it is never shared with other clients, never used to train base models without explicit authorization, and outbound portability — exporting or deleting data at the end of the engagement — is defined during the Assessment, not left implicit. On ownership of the components built specifically for the project (pipelines, prompts, configurations) we don't publish a generic clause here: it depends on what is client-specific versus a reusable part of our method, and is defined in each project's contract.

Integration with existing systems

The system connects to the client's existing management software, ERP, CRM, records management, and databases through the available APIs, without duplicating tools already in place: the goal is to fit inside the existing infrastructure, not replace it. Access permissions inherit the roles and policies already configured in the organization. The exact scope of systems to integrate is mapped during the Assessment, before any development.

Access management and permissions

System access permissions follow the roles and policies already in use within the client organization, not a standalone model. Before going into production, every project includes a cross-check of roles, access and data segregation.

Audit trail and logging

Every source consulted, action executed and decision the system assists with is recorded in a verifiable way, with reference to the originating data. Technical and application logs are retained according to policies agreed with the client, consistent with their sector's audit requirements: there is no standard retention period valid for every project, and we don't publish one here to avoid implying one that doesn't apply to your case.

Incident management

High-impact actions remain subject to explicit human confirmation: it's the first line of control against anomalous system behavior. Escalation procedures and incident response times are defined for each project together with the client, consistent with their existing incident-management processes — we don't publish a generic SLA here, because it depends on the operational context and the system's criticality level.

Security testing before release

Every system goes through four phases before production release: threat modeling, to identify the abuse scenarios most relevant to that specific process; red teaming, with targeted attempts to bypass guardrails or manipulate the system prompt; accuracy and behavior testing on real cases, not just prepared examples; and a cross-check of roles, access and data segregation.

Certifications and standards

ISO 9001 (quality management) and ISO 27001 (information security) are in the certification process; alignment with the NIS2 directive is progressing incrementally. On GDPR we don't claim general compliance — it doesn't exist as such, it's specific to each processing activity — but we design systems according to technical and organizational measures aligned with the applicable obligations: minimization, segregation, access management, traceability. The progress of each certification is listed on the Security and Governance page.

Infrastructure and cloud providers

We work with both open-source models and PaaS services from the major cloud providers — AWS, Azure, GCP — choosing case by case based on cost, performance, data residency and the client's security constraints: we are not tied to a single model provider. The list of third-party providers actually involved in a project is shared with the client as part of the technical documentation, because it varies from project to project.

Business continuity

The choice between cloud, on-premise and hybrid directly affects continuity: in the cloud it depends on the provider's SLAs, on-premise it's under the client's direct control, in a hybrid configuration redundancy is spread across both layers. We don't publish a generic guaranteed uptime: it's a parameter agreed per project, based on the system's criticality.

Model lifecycle and continuous improvement

After release, results are reviewed periodically: updating data and prompts, calibrating thresholds, adapting the system to changes in the process. It's a project phase agreed from the Assessment onward, not a separate service to renegotiate later.