001 / Security Posture
Security is a property of the deployment, not a vendor claim.
The security posture a customer experiences depends on how their deployment is configured against their policy — not on a fixed property of the platform. A customer running in air-gapped mode has a materially different security envelope than a customer running in public cloud. Both are valid. The platform is the same in each case; the controls that bind it are different.
Everything on this page describes capability. Which capabilities are engaged in a specific deployment is determined by the customer's policy file, applied by FrIdA, and reflected in the audit record. Compliance committees evaluating Saptiva AI should read this document alongside the specific deployment configuration proposed for their environment — not as a substitute for it.
002 / Data Residency
Where data lives, runs, and returns.
Residency is enforced by architecture, not by trust. FrIdA will refuse to dispatch a workload that carries data of a class the policy does not permit to execute at the proposed compute target. The customer defines the classes. The platform enforces them.
MEXICO
In-country compute
CNBV / CNSF / CONDUSEF residency satisfied by architecture. KAL runs here. Sovereign regions and on-premise, inside Mexico.
BRAZIL
BACEN-aligned
LGPD residency satisfied by configuration. Sovereign and private cloud, inside Brazil.
CHILE
CMF-aligned
CMF expectations honored for financial and insurance workloads. Private cloud and on-premise, inside Chile.
COLOMBIA
SFC / SIC-aligned
SFC-supervised and SIC-regulated workloads deploy in-country, on partner infrastructure.
CENTRAL AMERICA
Regional
In-market deployments serving tier-1 financial institutions. On-premise and private cloud.
AIR-GAPPED
Zero external connectivity
Air-gapped deployments for defense, critical infrastructure, and the most regulated government and financial workloads.
For deployments where residency is a defining requirement, we publish the physical region, the legal jurisdiction, and the contractual residency commitment in the customer agreement. The claim on this page is not the commitment. The commitment is in the MSA.
003 / Encryption & Keys
Cryptographic posture.
TLS 1.3 for all external traffic. Mutual TLS for service-to-service inside the deployment. No unencrypted network paths in production.
AES-256 for all stored data. Per-tenant key scoping. Storage-layer encryption is additive to application-layer encryption for sensitive fields.
Customer-held keys supported in sovereign, private, and on-premise deployments. HSM integration available. In public cloud mode, keys managed via the cloud provider's KMS with customer-controlled policies.
Automated rotation on a configurable schedule. Default is 90 days for data-at-rest keys. Audit record captures every rotation event.
Model weights are treated as customer-scoped data where applicable. Fine-tuned customer models never leave the customer's deployment environment.
004 / Access Controls
Who can do what, to which data.
01 / IDENTITY
SSO and directory integration
SAML 2.0 and OIDC. Integrates with the customer's directory (Active Directory, Okta, Azure AD). Saptiva AI does not maintain a separate identity provider for production users of customer deployments.
02 / RBAC
Role-based access controls
Roles defined in the customer's policy file. FrIdA enforces role → capability mapping on every dispatch. Access decisions appear in the audit record with the role and justification captured.
03 / LEAST PRIVILEGE
Capability-scoped sessions
Application access is scoped to the specific capability needed for the task. A credit officer's copilot session does not see KYC data unless explicitly permitted.
04 / MFA
Multi-factor enforced
MFA required for administrative access and for production workloads touching regulated data. Enforcement tied to the customer's directory policy.
05 / PRIVILEGED ACCESS
Saptiva AI operator access
Saptiva AI personnel do not have standing access to customer production data. Operational intervention requires customer-authorized, time-bounded access tied to a specific incident or work order, with full session audit.
06 / SESSION GOVERNANCE
Session timeouts and re-auth
Configurable by the customer. Defaults follow banking-grade expectations. Re-authentication required for privileged operations regardless of session state.
005 / Audit Surface
The record is the deliverable.
Every FrIdA dispatch produces a signed, immutable audit record. The record captures what model ran, on what data, under which policy version, authorized by which identity, and with what outcome. It is the object a regulator, internal audit, or post-incident investigation examines — not a log file, but a structured record.
- Signed and immutable. Each entry is cryptographically signed. Tampering breaks the signature chain.
- Retention in-country. Audit records are retained inside the customer's jurisdiction, under the customer's retention policy.
- Exportable on demand. Customer can export the audit record in structured form for ingestion into internal SIEM, compliance tooling, or regulator-specific formats.
- Coverage includes Saptiva. Any Saptiva-personnel access to the environment appears in the same audit record, on the same terms.
- Default retention is seven years. Configurable up or down per the customer's regulatory framework.
006 / Regulatory Alignment
The frameworks we deploy under.
Saptiva AI does not claim certification against every regulatory framework in Latin America. What we do claim is deployability under each of the frameworks listed below. Our customers operating under them have cleared their internal risk review to run production workloads.
FRAMEWORK
DEPLOYMENT POSTURE
Production deployments active. Residency, audit, and access controls satisfy CNBV expectations as reviewed by customer compliance committees.
CNSF (Mexico · Insurance)
Production deployments active. Document processing and customer operations workloads operating under CNSF oversight via customer's compliance framework.
Deployment-ready. Residency and LGPD-adjacent expectations satisfied by sovereign deployment options.
Deployment-ready. Scoping conversations underway with regulated institutions.
SFC (Colombia · Financial)
Deployment-ready. Scoping conversations underway with regulated institutions.
FATF / Basel (AML · Regional)
AML-adjacent workflows (SAR preparation, transaction review support) deployed with full audit and explainability. Explainability is a first-class requirement, not an add-on.
Data subject rights, residency, and processing lawfulness supported by platform primitives. Customer remains the data controller.
007 / Certifications
What we have. What we don't yet.
Honest posture
Saptiva AI does not yet hold a completed SOC 2 Type II attestation. We are in the formal readiness and assessment phase with a qualified assessor. We expect completion in the current fiscal year and will publish the attestation date when it is signed.
ISO 27001 is in scope for the following fiscal year. We intend to pursue it because our enterprise customers ask for it — not because it materially changes our production security posture, which is already governed by the controls on this page.
If your compliance framework requires a completed SOC 2 or ISO 27001 attestation before a vendor can be onboarded, we can share our current readiness artifacts under NDA and connect your compliance team with our security lead. We prefer to say so up front rather than have the conversation surface at procurement.
We hold the following operational certifications and alignments:
- GDPR-aligned data handling — applicable where the customer has GDPR-scope obligations.
- CSA STAR Level 1 — self-assessment submitted to the Cloud Security Alliance registry.
- NIST Cybersecurity Framework alignment — our internal control framework maps to NIST CSF.
008 / Subprocessors
Who touches the data, beyond us.
The subprocessor list depends on the deployment mode. Air-gapped deployments have no subprocessors. Public cloud deployments inherit the cloud provider as a subprocessor. Sovereign and on-premise deployments may or may not involve additional subprocessors depending on the customer's configuration.
For each customer engagement, we publish the active subprocessor list in the DPA and notify the customer in advance of any change. The canonical subprocessor list is available under NDA to prospective customers; active customers receive it as part of their DPA.
CATEGORY
TYPICAL SUBPROCESSORS
Public cloud deployments: AWS, Microsoft Azure, or Google Cloud, depending on customer selection. Sovereign deployments: the in-country operator of the sovereign region. On-premise: none.
HPE, Dell, and NVIDIA through distribution partnerships for on-premise and hybrid deployments. These parties distribute hardware; they do not process customer data.
Saptiva-employed Forward Deployed Engineers and operational staff. Third-party operational subprocessors are not routine; any use is disclosed to the customer in advance.
Depends on deployment configuration. Customers may run open-weight models with no external model subprocessor. Where commercial models are used, the provider appears as a subprocessor for that specific workload.
009 / Incident Response
When something goes wrong.
Our incident response posture is built around timely customer notification, joint technical response, and post-incident transparency. The specifics are governed by the MSA and DPA for each customer.
- Notification within 72 hours of confirmed security incident affecting the customer's environment or data. Shorter notification windows available by contract for regulated customers whose frameworks require them.
- Joint response protocol. Saptiva security leadership engages with the customer's incident response team directly — we do not route through sales or account management during an active incident.
- Post-incident report. Structured report covering timeline, impact, root cause, remediation, and preventive changes. Shared within a timeline defined by the MSA.
- Reporting channel for external parties. Security researchers and external reporters can contact us through the channel on this page. Responsible disclosure is welcomed.