Responsible AI & AI Governance Policy

1. Purpose

IntegrityXapplies AI to the detection of financial leakage — fraud, non-fraud loss and optimisation opportunity — in client financial and operational data. Findings from that analysis can affect vendors, employees and commercial relationships. That consequence is the reason this policy is drafted tightly and enforced, rather than published as a statement of aspiration.

2. Scope

This policy covers every AI-enabled component of the IntegrityX platform: the multi-agent reasoning layer, all third-party foundation models accessed through APIs, retrieval and extraction components including OCR and layout models, and any automated scoring, ranking or classification that contributes to a finding presented to a client.

It covers all IntegrityX personnel, contractors and advisers with access to AI systems or client data, and it extends contractually to AI sub-processors. It sits alongside the Information Security Policy and does not displace it.

3. Definitions

4. Governing Principles

Eight principles govern every AI decision at IntegrityX. They are stated as obligations, not values.

4.1 Client data does not train models

No client data is used to train, fine-tune, benchmark or otherwise improve any IntegrityX model, any shared or global model, or any provider's model. This is enforced contractually through no-training and zero or limited-retention terms in every AI sub-processor agreement, back-to-back with the obligations IntegrityX owes its clients. It is a warranty capable of being written into the client MSA or DPA, not a preference.

4.2 A finding without evidence is not a finding

Every finding must carry provenance to the source record — document and page, or table and row. Output that cannot be traced to a source is not surfaced to a client. Model fluency is not evidence.

4.3 A human decides

The platform detects and evidences; it does not decide. No adverse action against any person or organisation is taken automatically or on the platform's authority. Human review by the client is a required step before any finding is acted on, and the platform is configured so that this step cannot be bypassed by design.

4.4 No single model is trusted alone

Material findings are corroborated across more than one foundation model under a multi-model consensus design, with output schema validation applied to every model response. Disagreement between models is treated as a signal to be examined, not an error to be averaged away.

4.5 Personal data is minimised before it reaches a model

Personal data is masked by default within the platform, with unmasking gated by role, reason and audit. A best-effort minimisation control reduces personal data in content sent to AI sub-processors. Section 15 records the current maturity of that control honestly.

4.6 Every AI call is logged

Each AI call made by an agent is recorded in a tamper-evident, hash-chained audit trail. AI behaviour at IntegrityX is reconstructable after the fact, by the client and by an auditor acting for the client.

4.7 Uncertainty is disclosed, not smoothed

Where confidence is low, the platform says so. Findings are presented with their basis and their limits. IntegrityX does not present a probabilistic output as a certainty in order to make a report read better.

4.8 Security of the AI layer is continuous, not periodic

An agentic platform changes continuously, so its assurance must too. IntegrityXis building an Agent SOC — continuous, agent-based monitoring of its own platform — on the view that point-in-time attestation describes a system as it stood on a date and is dated the moment it is issued. Certification is pursued because clients and regulators reasonably require it; it is not what security rests on.

5. AI System Inventory and Risk Classification

IntegrityX maintains an inventory of every AI system in the platform, recording its purpose, the models it calls, the data categories it processes, its output type, and its risk classification. The inventory is reviewed at least annually and on the introduction of any new model, provider or use case.

Findings about vendors, employees or counterparties are classified High by default. A classification may not be lowered without written approval from the policy owner.

An AI impact assessment is completed before any High-classification system is deployed or materially changed, covering intended use, affected parties, failure modes, the consequence of a false positive and of a false negative, the mitigations applied, and the residual risk accepted.

6. Model and AI Sub-processor Governance

IntegrityX uses third-party foundation models through provider APIs. It does not host, train or fine-tune a foundation model of its own.

Cross-border processing for AI inference is disclosed to clients in writing and is not concealed within a general sub-processor clause. Storage and compute for the platform itself remain in India (Google Cloud, asia-south1).

6.1 Adding or changing a model or provider

A new model or provider may not be introduced into a High-classification path until: due diligence on the provider is complete; a data processing agreement with no-training and retention terms is executed; the change is recorded in the AI inventory and the AIBOM; an AI impact assessment is updated; and the policy owner has approved it. Clients are notified of a change of AI sub-processor in accordance with their agreement.

6.2 AI bill of materials

IntegrityX maintains an AIBOM alongside its software bill of materials, in CycloneDX format, recording AI components and their dependencies. It is available to clients for review.

7. Data Governance for AI

• Purpose limitation — client content is processed only to deliver the leakage detection service the client has instructed. It is not used for product research, benchmarking, marketing or any secondary purpose.
• Minimisation — only the data required for the analysis is sent to a model. A best-effort control reduces personal data in AI-bound content.
• Masking — personal data is masked by default in the platform. Unmasking requires an authorised role and a recorded reason, and is logged.
• Residency — platform storage, compute and backups are in India. AI inference locations are as stated in section 6.
• Retention — client uploads are purged 30 days after processing. Provider-side retention is governed by zero or limited-retention terms. A data deletion certificate is issued on request and on offboarding.
• Prohibited inputs — cardholder data, biometric data and special-category data outside the agreed scope are not to be ingested. Where such identifiers appear incidentally they are masked or redacted.
• Role under data protection law — IntegrityX acts as a Data Processor. The client is the Data Fiduciary and is responsible for the lawful basis and for data-principal consent.

8. Human Oversight

Human oversight is a control, not a courtesy, and this section states where it is mandatory.

• No adverse action may be taken on the basis of a platform finding without human review by a competent person at the client.
• Findings concerning an identified individual — an employee, a vendor's officer, a counterparty — are always High classification and always require review.
• A reviewer must be able to see the evidence behind a finding, not only its conclusion, and must have authority to reject or vary it.
• Where a finding is rejected on review, the rejection is recorded. Systematic rejection of a finding type is treated as a defect in the detection logic and is investigated.

IntegrityXdoes not operate the client's decision process and does not represent a finding as a determination of guilt, fraud or misconduct. A finding is an evidenced indication that a matter warrants examination.

9. Accuracy, Evidence and Contestability

Accuracy controls in operation: multi-model consensus on material findings; output schema validation on every model response; provenance recorded per finding to source document and page; canonical records rather than model recollection used as the basis of reasoning; and human review of findings before release.

Contestability. A client, or a party affected by a finding through the client, may ask how a finding was reached. IntegrityX will provide the evidence chain, the records relied on and the analytical basis. The audit trail is designed to make that answer possible years after the event.

False positives are expected in detection work and are treated as an ordinary operating cost rather than an embarrassment to be hidden. False-positive patterns are reviewed and fed back into the detection logic through change management.

10. Fairness and Non-discrimination

IntegrityX analyses transactions, documents and entity relationships. It does not build models that score individuals on demographic characteristics, and protected characteristics are not used as detection features.

Two risks are acknowledged rather than dismissed. First, proxy risk: features such as location, vendor size or language of documentation can correlate with protected characteristics, and detection logic is reviewed with that in mind. Second, review-burden concentration: if findings cluster persistently on one supplier segment, business unit or region, that pattern is examined for whether it reflects genuine risk or an artefact of data coverage.

Where a fairness concern is identified, it is logged and remediated through the same change-management route as a defect.

11. Transparency and Disclosure

• Clients are told which foundation model providers are used, where inference occurs, and on what contractual terms.
• AI-generated narrative in a report is identifiable as such, and is always accompanied by the underlying evidence.
• IntegrityX does not claim that its outputs are produced without AI, and does not present AI-generated text as human analysis.
• Platform limitations relevant to a client's use case are disclosed during scoping, not discovered by the client in production.
• This page is the public summary of the policy, maintained so that a party affected by an analysis can see the standard applied to it.

12. Security of AI Systems

AI systems introduce failure modes that conventional application security does not fully address. The controls applied are:

13. Change Management for AI

Changes to prompts, agent definitions, model selection, detection logic and output schemas are changes to a control surface and are managed as such: raised through a pull request, categorised Minor, Major or Enhancement, reviewed by a second person, gated on automated tests and lints, validated in staging, deployed in stages with rollback, and recorded in the audit trail. A change affecting a High-classification system additionally requires an updated AI impact assessment and approval by the policy owner.

14. Monitoring, Logging and Audit

• Every AI call by an agent is logged with model, agent, tenant, user context, timestamp and correlation identifier.
• The audit trail is SHA-256 hash-chained and tamper-evident, retained for up to seven years, and is not user-deletable.
• Access to personal data is logged with the reason given for unmasking.
• Anomaly detection operates on authentication and access logs and raises security alerts with a tracked workflow state.
• Clients may audit IntegrityX's AI controls, directly or through a regulator acting for them, where their agreement provides for it. IntegrityX will not refuse an audit of the controls stated in this policy.

15. Known Limitations

Stating what is not yet in place is part of governing it. As at the effective date of this policy:

Each item is tracked with an owner. Progress is available to clients on request. IntegrityX will not describe any of these as complete before it is.

16. AI Incidents

An AI incident is any event in which an AI system produces materially incorrect output that reaches a client, exposes data through inference, behaves outside its defined agency, or is manipulated through injected content. AI incidents are handled under the Incident Management Policy with the same severity scale and notification obligations, including notification to affected clients without undue delay and within 72 hours of confirmation for a personal-data breach.

Additionally, where incorrect output has reached a client, IntegrityX notifies that client, identifies every finding affected by the same defect, and states plainly what was wrong. Withdrawing an incorrect finding is treated as an obligation, not a reputational choice.

17. Framework Alignment

This policy is structured against three reference frameworks. Alignment is claimed; certification is not, and section 15 says so.

Where a client is subject to sectoral obligations — RBI or SEBI outsourcing expectations, or an equivalent regime — IntegrityX will support those obligations, including right-to-audit and sub-contractor transparency, through the client agreement.

18. Accountability, Review and Contact

This policy is owned by the Chief Risk Officer of IntegriAI Private Limited, who approves risk classifications and AI impact assessments, approves the introduction of new models and providers, and decides escalations. Engineering implements and maintains the controls and the AI inventory; Information Security handles AI incidents, monitoring and sub-processor security review; the advisory team provides independent challenge on the domain appropriateness of detection logic and on fairness concerns.

The policy is mandatory across IntegrityX. Exceptions may be granted only in writing, with a stated scope, a compensating control and an expiry date. No exception may be granted to principle 4.1 (client data does not train models) or to the human-oversight requirement in section 8.

The policy is reviewed annually and on any material change to models, AI sub-processors, use cases or applicable law. Each review is recorded with a date, the reviewer and the outcome.

To ask how a finding was reached, to request the controlled version of this policy, or to raise a concern about the AI described here: