Trust Center

Enterprise trust, in writing

Buyers evaluate governance before features — rightly. This page documents how we handle security, privacy, human oversight, and accountability across our products and client implementations, and names the work we refuse. If your diligence needs more, ask us directly.

Last updated: 5 July 2026

Human oversight & responsible AI

Every system we build follows one architectural rule: AI recommends, ranks, drafts, and extracts — named humans decide. Consequential decisions (rejecting a candidate, approving a payment, sending a customer reply in a new category) are recorded human actions with reasons attached.

This is not a configuration option that can be quietly switched off. In our products, silent auto-rejection does not exist as a feature. In client implementations, human decision gates are specified in the design phase and verified before go-live.

Confidence thresholds route uncertain AI outputs to people automatically. Where an AI system cannot ground its output in verifiable evidence, it escalates rather than guesses.

Explainability & auditability

A recommendation that can't be explained can't be defended — to a hiring manager, a client, a candidate, or a regulator. Our systems attach evidence to their outputs: CandidRanker scores carry the specific skills matched, gaps found, and seniority signals behind each ranking; document extractions carry field-level confidence scores and source references.

Every automated step and every human decision is logged: what the AI produced, who decided, what they decided, and why. The audit trail is an architectural byproduct, not a report someone assembles later. Most clients end up with stronger decision evidence than their previous manual process ever produced.

We publish the measurement methodology behind every performance figure we cite — 12,400+ resumes per quarter, 94% shortlist acceptance — so claims can be checked, not just believed.

Data privacy — DPDP & GDPR

We operate from India and design for India's Digital Personal Data Protection Act 2023 (DPDP) as the baseline, with EU/UK GDPR alignment for international engagements. In every implementation, data flows are documented before anything is built: what personal data is processed, by which systems and models, where it resides, who can access it, and how long it is retained.

Scope minimization is the first control — systems only see the data their function requires. Processing can be scoped to approved providers or private deployments where residency or confidentiality requires it. Consent on our own forms is explicit, recorded with timestamp and policy version, and enforced server-side.

Our full privacy practices are documented in the Privacy Policy, including data-subject rights and our grievance contact.

Security architecture

Client systems are built with role-based access control, encrypted transport (TLS) and storage, environment separation between development and production, and least-privilege service accounts. Credentials and secrets are managed outside code and rotated.

Integrations begin read-safe: automation earns write access to production systems only after accuracy is demonstrated in the pilot against your baseline. Every automated write is logged and reversible by design.

Access to client data within Hab is restricted to the engagement team, under confidentiality obligations, for the duration the engagement requires — and removed when it ends.

Implementation governance — the 4D checkpoints

Governance is embedded in the engagement method itself, so it cannot be skipped under delivery pressure:

  • Diagnose — a measured baseline is recorded before any system is built. No baseline, no pilot.
  • Design — data flows, oversight points, DPDP/GDPR obligations, and failure modes are documented and reviewed with your stakeholders before code.
  • Deploy — bounded pilot on one process, in parallel with the existing process until accuracy is proven. A named owner on both sides.
  • Deliver — results reported against the baseline, honestly, including what didn't work. Scaling is a decision you make on evidence, not momentum.

The full methodology is public on our Approach page — including the governance commitments we make on every engagement.

Support, continuity & accountability

Engagements are founder-led: you deal directly with the person accountable for the outcome. Every deployed system ships with plain-language documentation, trained operators on your team, and a defined support arrangement — response expectations are agreed in the engagement scope, not discovered during an incident.

We build for your independence, not our lock-in: systems are documented well enough for a competent third party to maintain, data remains yours and exportable, and integrations use your existing systems of record rather than replacing them.

If a deployed system underperforms its baseline, that is our problem to fix — the measured-results model means underperformance is visible, on the record, and ours to answer for.

What we refuse to build

Some requests we decline, regardless of budget:

  • Fully automated rejection of people — hiring, lending, claims, or otherwise. Consequential decisions about people keep a human decision-maker. Always.
  • Systems designed to obscure their own reasoning — if the intent is that nobody can ask "why", we're the wrong partner.
  • Surveillance dressed as productivity analytics — monitoring tools whose real purpose is intimidation.
  • AI theater — deployments whose purpose is an announcement rather than a measured operational result. The audit will say so, and we'd rather lose the project than fake the number.

Questions about any of this — including security questionnaires and procurement due-diligence requests — go to haribharathi@habsolutions.cloud. We answer them directly.