India AI and Responsible Technology

How we build, test, document and govern the models — and the limits we accept on what they may be used to decide.

1. Why this exists

DECTIFY's models make claims about people: that a face resembles another face, that a plate reads a certain way, that a person in one frame is the person in another. Each claim can be wrong, and each can be wrong more often for some groups than others. This policy governs how we manage that.

India has no binding horizontal AI statute. We therefore work to the instruments that do exist and treat them as binding on ourselves:

• India AI Governance Guidelines issued by the Ministry of Electronics and Information Technology.
• NITI Aayog's Responsible AI for All principles — safety and reliability, equality, inclusivity and non-discrimination, privacy and security, transparency, accountability, and protection of positive human values.
• Digital Personal Data Protection Act, 2023, which governs the personal data our models consume and produce.
• Article 14, 15, 19 and 21 of the Constitution, which frame what a surveillance system deployed by or for the State may lawfully do, and the proportionality test in K.S. Puttaswamy v. Union of India.

2. Our principles, stated as constraints

3. The model lifecycle

3.1 Problem definition and risk classification

Every proposed capability is classified before work starts, by the severity of the consequence if it is wrong. Capabilities that can contribute to identification, detention, denial of access or enforcement are classified high-risk and require an impact assessment, executive approval and a documented human-review design before any development begins.

3.2 Training data

• Provenance is recorded for every dataset: source, licence, collection basis and permitted use.
• Customer Data is excluded unless that customer has affirmatively opted in, per product, in writing, revocably.
• Datasets are assessed for demographic composition, and gaps are recorded in the model card rather than quietly tolerated.
• We do not scrape faces from the open web to build galleries or training sets.

3.3 Evaluation

• Held-out evaluation sets, disjoint from training data and not drawn from Customer Data.
• Disaggregated error reporting: false match and false non-match rates by demographic group where the evaluation set supports it, and an explicit statement where it does not.
• Stress evaluation across the conditions that actually degrade field performance — low light, oblique angle, distance, occlusion, motion, weather, compression.
• A release is blocked where a disaggregated error rate materially exceeds the aggregate, until the gap is closed or the capability is restricted.

3.4 Model cards

Every model in a released product ships with a card stating intended use, out-of-scope use, evaluation methodology and datasets, measured performance including disaggregated rates, known failure modes, degradation conditions, the recommended confidence threshold and the basis for it, and the version and date. Cards are available to customers and to their regulators, and are updated on every model change.

3.5 Deployment

• Conservative default thresholds. Raising a threshold is free; lowering it requires a recorded authorisation and is surfaced in the customer's review report.
• Confidence is displayed with every result. There is no interface that presents a match without its score.
• The mandatory review step cannot be turned off, defaulted or bypassed through the API.

3.6 Monitoring and withdrawal

Confirmed false positives reported by customers are logged, categorised and reviewed on a fixed cadence. Where a pattern emerges we notify affected customers, and we will raise a default threshold, restrict a configuration, or withdraw a capability entirely. We would rather withdraw a feature than defend a number.

4. Governance

Roles are held by named individuals recorded at [governance roster]. A person who owns a revenue target for a capability does not hold the approval right over its release.

5. Uses we decline

We turn down business. The following are declined at the deployment review stage regardless of value:

• Untargeted identification of the general public.
• Profiling by religion, caste, ethnicity, or political or trade union affiliation.
• Monitoring of lawful protest, assembly, worship, journalism or legal representation.
• Social scoring, or any system that aggregates behaviour into a rating attached to a person.
• Emotion, intent or deception inference in any setting.
• Deployment where the customer will not accept the human-review obligation.
• Deployment where the customer cannot evidence lawful authority over the site or the feeds.

6. Explaining an output

On a customer's request in respect of a specific decision, DECTIFY will provide the model version, the confidence score, the threshold in force, the imagery the output was derived from, the audit record of who reviewed it and when, and the relevant model card. We will not provide model weights or training data, and we will not manufacture a post-hoc rationalisation of a probabilistic result. Where a Data Principal asks how a decision affecting them was reached, the customer is the Data Fiduciary and answers; we supply the technical record it needs.

7. Reporting a harm

If you believe a DECTIFY system produced a wrong or harmful result, write to responsible-ai@dectify.in. Reports may be anonymous. We acknowledge within three (3) business days, investigate, and tell the reporter what we found and what we changed, unless doing so would disclose a customer's confidential information. Reports and outcomes are counted in the report at Compliance and Security Updates.