How we protect your data

This is a courtesy translation provided for convenience. The Spanish version is the legally binding text.

01. Authentication and access

• Corporate emails authenticated with DKIM, SPF, and DMARC on the aiginer.com domain. This prevents third parties from spoofing internal addresses in phishing attempts.
• Two-factor authentication enabled on the administrative accounts of the external providers that keep the service running: hosting, repositories, DNS and email. In the Shara product, a TOTP second factor is available on every account and each customer company can require it of its whole team from its settings, in which case anyone without it is locked out.
• Access to the production server only via SSH keys (no password). Keys are rotated when a collaborator no longer needs access.
• Client panel sessions protected with short-lived signed tokens and controlled refresh.

02. Encryption

• HTTPS enforced across the entire site via Cloudflare with TLS 1.2+ and active HSTS preload (HTTP is completely blocked).
• Sensitive data encrypted at rest within the production database, with the master key kept outside the repository.
• Authenticated symmetric encryption (AES-256-GCM) for third-party credentials that clients delegate to us to manage (a vault with data associated to the tenant to prevent cross-client exposure).

03. Per-client data isolation

• Isolation is enforced in the application: every endpoint verifies the user's membership in the organisation, and every query carries that filter before it touches the database.
• And on the usage and money path — model consumption, billing and approvals — the database enforces it a second time, independently: Postgres row-level security is enabled and forced, and the query drops privileges before it runs, so it stays restricted to your organisation's rows even if the application had a logic flaw. In the remaining domains, isolation rests on the previous layer while we extend that second barrier. An automated check blocks a release if a new table in an already-covered domain ships without a policy.
• We never use one client's data to train models or to benefit another client.

04. Cryptographic traceability of actions

• Every sensitive action (configuration changes, administrative access, data exports) is logged in an audit_logs table.
• Each record includes a SHA-256 hash linked to the previous record. This forms an immutable chain: any tampering or subsequent deletion is detected when the verification is run.
• For regulated clients, these records constitute admissible evidence: we can demonstrate who did what and when, with no possibility of silent modification.

05. Backups and disaster recovery

• Full dump (pg_dump) of every production database daily, encrypted with AES-256 and stored with its SHA-256 checksum. Seven daily copies and four weekly ones are kept, along with the production configuration.
• 3-2-1 rule: three copies, two media, one off-site. Beyond the production server, every copy is replicated to object storage under European Union jurisdiction, and a fourth goes to a separate physical machine. Everything that leaves the server travels already encrypted: the storage provider never sees anything in the clear.
• Automated monthly restore drill: we load a full backup into an isolated environment and verify the integrity of the audit_logs hash chain. If the chain fails verification, the copy is discarded.

06. Network and anti-bot protection

• Cloudflare WAF active with a managed ruleset and custom rules that block known scanners (attempts on /wp-admin, /.env, /phpmyadmin, etc.).
• Automatic managed challenge for suspicious traffic and unverified bots, with search engines explicitly excluded. We do not use the blanket anti-bot mode: turning it on was part of what kept this site out of Google for 45 days, and we would rather have a rule that can tell a legitimate crawler from a scanner.
• Invisible Cloudflare Turnstile on all public forms (contact, audit). Combined with a hidden honeypot and minimum-fill-time validation, this blocks virtually all spam and form-scraping attacks.
• Rate limiting on the intake webhooks.

07. Monitoring and incident response

• Public status page at status.aiginer.com with 11 monitored components across application, API, models and infrastructure, with the uptime history in plain view.
• Every production service has its own health check and an automatic restart policy: if a container stops responding, it comes back up on its own, with no intervention.
• Independent watchdogs that email us when something quietly stops happening: for example, if backups stop running or if search crawlers start getting blocked.
• Real-time alerts sent to the internal channel so any degradation is addressed within minutes.

08. Confidentiality of the model stack

• Shara, our SaaS product, exposes models to clients using internal aliases (Prelude, Sonata, Symphony, Concerto). The actual provider behind each alias is confidential information.
• This protects you as a client: if a provider raises prices, degrades a model, or discontinues it, we replace it with an equivalent one without your team having to relearn anything.
• The stack details are only shared under NDA with Max and Local Plan clients, as part of the due diligence process.
• All models run on providers that comply with the GDPR and offer no-training clauses on client data.

09. Vulnerability reporting

• Dedicated addresses: security@aiginer.com (es) and security@aiginer.com (en).
• Committed response times: acknowledgment in under 24 business hours; substantive response with an action plan in under 5 business days.
• Patch deployed within 30 days for critical and high-severity vulnerabilities for which the vendor has published a fix. Where there is none, we apply mitigation and keep a record of it until a fix exists.
• Coordinated disclosure with the researcher: we give credit (if desired) and publicly announce the fix once it is in production.

10. Hardening roadmap (honest about what we don't have yet)

• Certifications: we hold none today. We are not certified under SOC 2 Type II or ISO 27001, and we would rather say so than imply an ongoing process. We will assess them when client volume justifies it; until then, what we offer are the concrete measures in this document, which you can actually verify.
• Restoring from the off-site copy: tested on 5 August 2026, with the dump downloaded, decrypted and verified table by table.
• Second database-level barrier for the rest of the platform: in migration. The money path already has it; the rest follows domain by domain.
• Independent external penetration test: planned pre-GA of the product.
• Public bug bounty: planned after the external penetration test. In the meantime, we maintain a responsible disclosure channel.

Have specific questions about our security?

If you need additional information for a procurement questionnaire, an internal audit, or a risk analysis, write to us. We handle reasonable requests without requiring a prior contract.

Back to the Trust Center.