Home / Platform / FrIdA
001  /  Orchestration Layer  /  Core Platform

FrIdA

Routes every workload. Logs every decision.

FrIdA sits between every AI application and every compute environment. It decides where workloads run, enforces compliance at execution time, and logs every decision — under your jurisdiction, against your policies, in your audit trail.

Model-agnostic
Any LLM. Any version.
Environment-agnostic
Cloud, hybrid, on-prem, air-gapped.
Policy engine
Residency, compliance, cost, latency.
Audit
Every decision, logged, defensible.
002 / Why It Matters

Most AI platforms enforce compliance after the fact.
FrIdA enforces it at execution time.

The difference is everything. In regulated markets, an AI workload that touched the wrong data or ran in the wrong jurisdiction is not fixable in an audit report. It is a regulatory event. A compliance officer defending a CNBV, BACEN, or CMF inquiry does not need a post-hoc explanation of what happened. They need proof the wrong thing could not have happened in the first place.

The old model

Run the workload wherever. Review the logs later. Hope the auditor accepts your explanation.

With FrIdA

Policies are constraints, not reports. Non-compliant workloads don't run. Every route that does run is logged, signed, and defensible.

003 / Capabilities

What FrIdA actually does.

01

Compute placement.

FrIdA reads every workload's metadata — data classification, customer jurisdiction, SLA, cost envelope — and routes it to the compute environment that satisfies every constraint. Public cloud for cost-optimized batch, on-prem for regulated data, air-gapped for sensitive workloads. The application developer never decides. The policy does.

MULTI-CLOUD HYBRID ON-PREM AIR-GAPPED
02

Policy enforcement at execution time.

Residency, compliance framework, data class, retention, encryption requirements — all evaluated before the workload dispatches. Policies are authored in code, reviewed like code, versioned like code. Non-compliant workloads halt. Compliant ones proceed with a signed policy evaluation attached.

CNBV BACEN CMF CNSF GDPR
03

Model routing.

FrIdA selects the optimal model for each task — open-source for sensitive data, commercial frontier models for low-risk general tasks, domain-specific fine-tunes for regulated workflows. Model choice becomes a policy decision, not a developer decision. When a new model releases, FrIdA can adopt it without touching application code.

OPEN-SOURCE COMMERCIAL DOMAIN-TUNED
04

Observability and audit.

Every decision FrIdA makes is recorded: which workload, which policy, which model, which environment, with what metadata, at what timestamp, authorized by whom. The audit log is immutable, queryable, and exportable. When audit asks, you have a defensible answer in seconds. Not a week of forensics.

IMMUTABLE QUERYABLE SIGNED 7-YR RETENTION
05

Environment-agnostic execution.

Customers change deployment strategies without rewriting applications. Migrate from public cloud to sovereign region. Add an on-prem cluster. Extend to a new country with different residency rules. The application code does not change. FrIdA re-plans the route.

ZERO LOCK-IN NO REPLATFORM PORTABLE
004 / Architecture

How FrIdA routes a workload.

Applications emit requests with metadata. FrIdA evaluates policies, selects compute and model, dispatches the workload, and writes an audit record. Every step defensible.

WORKLOAD INGRESS FrIdA DECISION ENGINE EXECUTION TARGETS A B C Application Request + data_class: pii + jurisdiction: MX Application Request + data_class: general + jurisdiction: BR Application Request + data_class: financial + jurisdiction: MX Application Request + data_class: defense + jurisdiction: MX Custom Workflow via FrIdA SDK FrIdA DECISION ENGINE RESIDENCY CHECK COMPLIANCE GATE MODEL ROUTING COST & LATENCY AUDIT WRITER IMMUTABLE · SIGNED · QUERYABLE Public Cloud AWS · AZURE · GCP Sovereign Cloud / BR BACEN-RESIDENT · ACTIVE On-Premise / MX CNBV-RESIDENT · ACTIVE Hybrid BURST TO CLOUD Air-Gapped DEFENSE · REGULATED ← AUDIT STREAM
005 / Policy as Code

Policies are authored, reviewed, and versioned.

Every FrIdA policy lives in your repository. Pull-requested. Reviewed by compliance. Signed off by risk. Deployed like any other piece of your production system. No shadow configuration. No manual gates. No surprises.

policies/latam_banking_residency.yaml
# Policy: LatAm banking residency + compliance
# Applies to: Tier-1 bank production workloads

apiVersion: frida.saptiva.ai/v1
kind: RoutingPolicy
metadata:
  name: latam-banking-residency
  version: 2.4.0
  owner: [email protected]

spec:
  applies_to:
    data_class: [pii, financial, kyc]
    customer_jurisdiction: [MX, BR, CL, CO]

  requires:
    residency: in_country
    provider_type: [on_prem, sovereign_cloud]
    encryption_at_rest: customer_managed_keys
    encryption_in_transit: tls_1_3

  forbids:
    providers: [us_hyperscaler_default_regions]
    models: [external_api_with_training_retention]

  audit:
    log_level: full
    retention: 7y
    signed_by: compliance_hsm

  on_violation:
    action: halt
    notify: [[email protected], [email protected]]
006 / Compatibility

Vendor-agnostic, by architecture.

FrIdA does not ship with a preferred model, cloud, or hardware stack. It routes across all of them. The compatibility matrix exists to make that explicit — not to sell you a particular option.

Models

  • OpenAI GPT family api · enterprise
  • Anthropic Claude family api · enterprise
  • Meta Llama family self-hosted · open weights
  • Mistral models self-hosted · api
  • Qwen, DeepSeek, Gemma self-hosted · open weights
  • KAL latam sovereign · nvidia-validated
  • Domain-specific fine-tunes customer-owned

Compute

  • AWS, Azure, GCP any region
  • Sovereign cloud regions br, mx, cl
  • Private cloud / VPC customer-operated
  • On-premise hpe, dell, nvidia
  • Air-gapped defense-grade isolation
  • Neo-cloud providers runpod, lambda

Integration

  • Identity saml, oidc, scim
  • Secrets vault, kms, customer hsm
  • Observability datadog, prometheus, splunk
  • Audit export siem, s3, customer warehouse
  • Data sources snowflake, databricks, postgres
  • Deployment kubernetes, terraform
007 / vs Alternatives

FrIdA is not the only way. It is the one that holds under audit.

Category
Structural limit
FrIdA
HyperscalersAWS · Azure · GCP
Jurisdiction lock-in. CLOUD Act exposure. US/EU compliance first; CNBV, BACEN, CMF second.
Vendor-agnostic. Residency enforced by design. Zero lock-in by architecture.
Data platformsDatabricks · Snowflake
Built for data orchestration and analytics. Not designed for AI execution governance or compliant model routing.
Governs AI execution — policy, placement, model routing, audit. Sits above the data platform, not beside it.
AI platformsPalantir AIP and peers
Deep, but often services-heavy and opaque. Adoption curve measured in quarters, not weeks.
Product-led, modular, interoperable. FDE-embedded delivery gets to production in two weeks.
Neo-cloudsRunpod · Lambda
Flexible, low-cost compute. No governance layer. No enterprise compliance surface.
Sits above them. Uses them where policy allows. Avoids them where it doesn't.
Internal buildIn-house platform teams
Slow, brittle, non-standardized across teams. Every compliance question becomes a new project.
Productizes control and scale. Compliant by design from day one. One platform, not ten.
008 / In Production
A Tier-1 Central American bank replaced stalled hyperscaler pilots with FrIdA. The governance constraints that blocked them for eighteen months were not a bug in the previous platform. They were the difference between AI that can run and AI that can't.
Deployment evidence Production · Banking · Central America
009 / Get In Touch

Bring your hardest deployment.

The workloads hyperscalers can't run. The compliance framework your systems integrator couldn't navigate. The pilot that stalled in procurement. A Forward Deployed Engineer will respond within 48 hours.

Request technical deep dive