Security, hosting, and data ownership: the facts buyers ask for

Can Saphenia run in your private cloud?

Saphenia runs in a cloud environment the customer controls or in a cloud Saphenia operates. A pilot or a first paid build costs less on Saphenia's cloud, and the deployment can move to your cloud for production.

Saphenia works with any model provider your firm already uses, and if you change models later, your decision logic, rules, and records stay in place.

For data that has to stay inside your firm's own cloud or region, scope the private deployment from the first meeting so the pilot and production run under the same hosting assumptions.

Does Saphenia use customer data to train models?

Saphenia does not train models on customer data, and a firm's data never trains anyone else's model. From your firm's documents and systems, Saphenia extracts the facts, definitions, and rules a decision depends on. Saphenia then structures them and enforces them on each answer an agent gives.

The judgment that lives in your experts' heads comes in through approved corrections. An expert reviews the agent's work and corrects it, and once approved, the correction becomes a rule every later answer follows. The correction is stored in your firm's own record of facts, rules, and decisions, with a note of where it came from.

For a security questionnaire, ask every vendor on the shortlist to state in writing which models are trained on your firm's data and where expert corrections are stored.

Who owns what Saphenia builds from a customer's data?

Each Saphenia customer owns everything Saphenia builds from their data outright: a durable, versioned record of what a firm knows and how they decide, with the source behind every fact. It holds the facts, definitions, and history from your systems of record, along with the judgment your experts add as they correct the work. It also holds the rules, instructions, source mappings, evidence, relationships, evaluation cases, and decision history.

If your firm leaves Saphenia, you take that record with you, including the decision logic, the rules, the proofs, and every record of how your firm decides.

A proof is the bundle an answer carries: the facts, the rule, the rule's version, and the date. Inside a proof, each piece of evidence is what a source contains, with an exact locator.

Write the ownership and export terms into the pilot agreement, and list that full record among the outputs your firm keeps.

What is Saphenia's current ISO 27001 and SOC 2 status?

Saphenia has ISO 27001 and SOC 2 certification in progress and holds neither certificate today.

If your policy requires a certificate before production, you can still run the pilot under your own vendor risk review. Production go-live then waits on the certificate your policy names.

Saphenia enforces the rules your firm sets, and regulatory compliance stays your firm's responsibility.

Security and data-access questions to settle before an agent pilot

Your firm should settle eight points before an agent pilot starts, each with an owner inside the firm and an answer in writing.

1. The decision. Name the one recurring decision the pilot will test. A deployment covers one workstream. Ask the vendor to list the sources it reads, and limit the pilot's data request to that list.
2. The sources and the access path. List each source system, who in your firm grants access to it, and whether the pilot reads copies or live systems.
3. Where it runs. Decide pilot hosting and production hosting at the start, and put the move between them in the plan.
4. Data that has to stay put. Mark every data set restricted to your firm's own cloud or region, since each one points to a private deployment from day one.
5. Training. Get the written answer on which models, if any, are trained on your firm's data.
6. Ownership and exit. Confirm what your firm takes away when the pilot ends, and in what form.
7. The output record. Confirm what each output records and who in your firm can read it.
8. Certification and reviews. Match the vendor's certification status to your firm's policy, and book the procurement, InfoSec, and model risk or compliance reviews before any pilot data is shared.

To judge whether the pilot works on your own documents, see how to evaluate a portfolio review pilot.

What each agent output records for a reviewer

Every output an agent produces on Saphenia ends in one of four outcomes, and each carries a record a reviewer can open.

• Fulfilled with proof. The answer ships with its proof, so an auditor can follow it back to its source.
• Refused by a rule. The answer would have broken one of the firm's rules, so it is never produced, and the refusal names the rule.
• A named gap. A fact the decision needs is missing, and the output says which one.
• Reserved for a human. The firm has set this call aside for a person, and the output goes to that person.

TechTarget's feature on decision trails states the limit of activity tracking: "A dashboard can show that an agent completed a step. It cannot prove that the agent should have completed that step." The four outcomes record the reason behind each step.

Every fact carries the period in which it was valid, and every rule is versioned, so a past decision can be re-run on the facts and rules that held at the time. For the broader argument, see deterministic AI agents.

How to move a pilot from vendor hosting to your own cloud

Ask for everything Saphenia built from your data to transfer, and confirm the move by re-running past decisions. Below is the move step by step, from a cloud Saphenia operates into your own.

1. Fix the target before the pilot starts. Record in the pilot agreement that production runs in your firm's cloud and that everything built from your data transfers.
2. Inventory what moves. Everything built from your data transfers, including the decision logic, approved corrections, and the proofs attached to past answers. Check that each fact keeps the period in which it was valid and each rule keeps every past version, because a move that drops either one leaves your firm unable to reconstruct past decisions.
3. Reconnect the sources inside your network. Each source the pilot used on Saphenia's cloud needs a new access path under your firm's own access controls. Budget for that integration work, since it adds to deployment cost (see what sets the cost of a deployment).
4. Re-run past decisions. Pick a set of decisions from the pilot record and run them again in the new environment, on the facts and rules that held at the time. Compare each outcome and its proof with the original.
5. Check every difference. A decision that now returns a named gap, or a refusal that cites a different rule version, shows something did not transfer. Trace each one to its cause before sign-off.
6. Change one thing at a time. If you also plan to switch model provider, make the move on your current provider first and run the comparison. Then switch provider and run it again, so you know which change caused a difference.
7. Sign off. The business-line owner signs off on the outcomes, and InfoSec signs off on the deployment.

Take a made-up mid-sized bank that piloted loan product matching on Saphenia's cloud for one product line. Before the pilot, the bank agreed that production would run in their own cloud. At the move, the team re-ran 40 past matches from the pilot record, and 38 returned the same outcome with the same proof. The other two had been fulfilled with proof in the pilot and this time returned a named gap, and both gaps named the same missing fact: the applicant's existing exposure. That fact sat in a credit register whose connection was never rebuilt inside the bank's network. Once the team reconnected the register and re-ran the two matches, each came back fulfilled with proof that matched the original. The Head of Credit signed off on the outcomes, and InfoSec signed off on the deployment.

Lenders keep changing their criteria after matching goes live. Loan product matching in production covers how the rules keep up.