Security & data ownership

01 · Architecture

Where the data actually goes.

Three zones. The interesting property is what doesn't cross between them.

Zone 1 · Yours

Your environment

Your cloud account or VPC. Your client data, your systems of record, your identity provider, your access policy. We do not hold a copy, and there is no replication to our infrastructure.

Zone 2 · Yours

The automation, running on your keys

Deployed beside your data rather than calling into it from outside. It uses your API keys, writes to your log sink, and authenticates through your identity provider. Every action it takes is recorded and attributable.

Zone 3 · Third party

Model API

Receives only the fields a given task needs — not the record, not the database. Configured for zero retention and no training. Region-pinned. Returns a completion and retains nothing.

The boundary is the line between zone 2 and zone 3, and the only thing that crosses it is the minimum payload for the task at hand. Nothing persists outside your environment. Every automated action is logged, attributable and reviewable.

02 · By delivery mode

Where your data lives depends on how you buy.

The architecture above describes the embedded mode, which is what we recommend and what most client-confidential work requires. Here is the honest comparison.

Aspect	Hosted API	Embedded in your environment	You own the code
Where your data is processed	Our infrastructure, in the region you choose	Inside your cloud or VPC only	Wherever you deploy it
Who holds the model API keys	Us	You	You
Can we see your client data	Only what you send to the endpoint	No — only what you grant during support	No
Where the audit log lives	Our infrastructure, exportable to you	Your log sink	Your log sink
What happens if we cease to exist	The endpoint stops; buy the code beforehand	It keeps running; you hold the deployment	Nothing changes
Suitable for client-confidential work	Case by case, with your client's terms in hand	Yes — this is the usual answer	Yes

Scroll the table sideways to compare all three modes.

03 · Model providers

The terms we configure, and why they matter.

Zero retention
Model calls are configured so the provider does not persist request or response content beyond the life of the call. This is a setting we enable per project and verify, not an assumption we inherit from a default.
No training on your data
Your data, and your clients' data, are never used to train or fine-tune a provider's model. Where we fine-tune anything for you, it is your model, in your account, on data you control.
Region pinning
Inference can be pinned to India, the EU or the US, so a data-residency clause in your own client MSA can be satisfied rather than argued about.
Minimum payload
The strongest control is architectural, not contractual: we send the fields a task needs and nothing more. Names, identifiers and salary data get redacted or tokenised before they leave zone 2 wherever the task doesn't need them.

Which specific providers a build uses, and in which regions, is agreed in the design week and named in the engagement documents — because the answer depends on what we're building and what your client contracts allow. We don't publish a list here that might be wrong for your engagement.

04 · Access controls

The controls we build in.

These are engineering decisions taken per engagement, agreed with whoever owns security at your firm during the design week.

Deployed in your cloud or VPC
Bring your own API keys
Zero data retention with model providers
Never used for training
Region pinning (India / EU / US)
Full audit trail of every action
Human approval gates on anything irreversible
Role-based access
Encrypted in transit and at rest
Single sign-on through your IdP
Field-level permissions
Data masking and tokenisation
Export or delete anytime
Source code purchasable

05 · Audit logging

"What did the AI do, and why?"

You will be asked this by your own client. A generic "we log everything" is not an answer, so here is the shape of an actual log line.

2026-08-24T09:14:02Z  run=r_8f31  actor=automation:screening  action=score.candidate
                      subject=cand_40219  rubric=consulting_v3  model=<configured>
                      inputs=sha256:9c1f…a7  score=72/100  confidence=0.81
                      rationale_id=rat_8f31_40219  region=ap-south-1  retention=none

2026-08-24T09:14:02Z  run=r_8f31  actor=automation:screening  action=rank.write
                      subject=cand_40219  position=14/312  queue=q_lateral_em

2026-08-24T09:14:03Z  run=r_8f31  actor=automation:screening  action=gate.hold
                      subject=cand_40219  gate=human_required:reject
                      note="no automated rejection is permitted"

2026-08-24T11:02:47Z  run=r_8f31  actor=user:s.rani@…       action=decision.advance
                      subject=cand_40219  agreed_with_score=true
                      next=schedule.interview  approved_by=user:s.rani@…

Every line is attributable
Automated actions carry the automation as actor; human decisions carry the person. You can always tell which one did what, which is the distinction your client's auditor actually cares about.
The reasoning is retrievable
Scores reference a stored rationale rather than being a bare number, so a decision can be explained months later without re-running anything.
Inputs are hashed, not copied
The log proves what was processed without becoming a second copy of the sensitive data it describes.
It lands in your log sink
In embedded deployments the trail is written to your own logging infrastructure, under your retention policy — not held by us and handed over on request.

06 · Human-in-the-loop

What never happens without a person.

The gates are agreed in writing during the design week and enforced in code, not left to configuration somebody can quietly loosen later.

Anything adverse to a person Rejections, adverse assessments, anything that affects someone's employment or candidacy. The system ranks and explains; a named person decides.

Anything that leaves your firm Client-facing documents, external emails, filings. Automation drafts; a person sends.

Anything that moves money Payments, write-offs, credit notes, vendor approvals. The exceptions get surfaced with the evidence attached so the decision is quick, not automatic.

Anything irreversible Deletion, overwriting a system of record, or any action with no clean undo. If it can't be walked back, it doesn't happen unattended.

07 · Ownership & exit

The exit is designed before the build starts.

Lock-in is the objection behind most security questions, so it's worth answering directly rather than through a data-flow diagram.

Source code purchase
An explicit option, priced up front at the start of the engagement, with a documented handover. It is never repriced at the moment you ask for it.
Your data is always yours
Export or delete at any time, in a documented format, without a support ticket or a negotiation.
No runtime dependency in embedded mode
Once deployed in your environment on your keys, the system does not phone home. If we vanished tomorrow it would keep running.
Ongoing service is separate and cancellable
Buying the code does not oblige you to keep us, and keeping us is not a condition of getting the code. Two decisions, priced separately.
Knowledge transfer on request
We'll train your team on the codebase and step back. If you hire engineers later, we hand over cleanly — that's a good outcome, not a lost account.

08 · Incident response

If something goes wrong.

Who to contact
A named engineer on the build, plus a written escalation path agreed at signing — not a shared inbox. Until an engagement starts, reach us at hello@wheelz365.com.
Notification
Notification timelines and obligations are set in the engagement contract against your requirements, because your obligations to your own clients are what determine ours to you.
Containment
In embedded deployments you hold the kill switch: revoke the keys or stop the service and the automation stops immediately, without waiting for us.
Reconstruction
Because every action is logged and attributable, "what did it touch" is a query rather than an investigation.

09 · Due diligence

Questions your security team will ask.

No — and we would rather say so here than have you find it in a questionnaire. What we offer instead is architectural: in the embedded mode your data never reaches our infrastructure, so the question largely collapses into controls you have already audited. If a certification is a hard procurement gate, tell us early and we will say honestly whether we can clear it in your timeframe.

Data processing terms are agreed per engagement, against your paper. We would rather review yours than ask you to accept ours.

Only the engineers on your build, only through access you grant and can revoke, and only for as long as you grant it. It goes through your identity provider, so it appears in your logs rather than ours. Where your policy forbids remote access to production we work on-site — a normal arrangement for us, not an exception.

In the embedded mode the only third party in the data path is the model provider, and which one is named in your engagement documents alongside its region and retention terms. No public list, because it would be a list of one and the one depends on your build.

Two ways, neither of which is "the model is good". Architecture: anything reaching a client passes a human gate by construction. And verification — where a fact matters we cross-check it against a second source and mark what could not be verified rather than filling the gap. A system that says "I don't know" is the one you can put in front of a client.

That is the case we build for. From your own logs, without calling us, you should be able to answer where the data went, what the system did, why it decided as it did, and who signed off. If you cannot answer those four, we built it wrong.

Your data stays inside your boundary. In writing.