ISO 42001 AI Governance for Indian IT Companies and Capability Centres

What ISO 42001 Requires

ISO/IEC 42001 is the international standard for an Artificial Intelligence Management System, usually shortened to AIMS. It follows the same harmonised structure as ISO 27001 and ISO 9001, covering context, leadership, planning, support, operation, performance evaluation and improvement, with an annex of AI specific controls behind it.

The subject matter is what differs. Rather than asking only whether information is protected, the standard asks whether your AI systems are developed and used responsibly across their whole lifecycle. In practice that means an inventory of AI systems, a policy defining what AI may and may not be used for, named accountability for each system, impact assessments considering the people affected by a model's outputs, controls over the data used for training and operation, transparency about where AI is involved, human oversight where decisions matter, and monitoring that catches drift and failure after deployment.

Certification follows the familiar route: an accredited body audits the system in two stages and the certificate is maintained through surveillance audits.

Who in India Needs It First

Three groups are feeling the pressure ahead of everyone else.

Capability centres come first. Global parents running engineering, analytics and product work from India increasingly apply group AI policies to their offshore units, and a board in New York or Frankfurt wants evidence that the Bangalore or Hyderabad centre operates to the same standard. An externally audited management system is the cleanest way to provide it.

IT services and BPO firms come second. Clients have started asking pointed questions about AI in delivery: whether client data is fed into third party models, whether outputs are reviewed before reaching end customers, and whether vendor staff can explain how a tool reaches its conclusions. Firms that already use CMMI to evidence delivery maturity, whether through our Hyderabad or Chennai teams, find AI governance appearing in the same questionnaires.

Product and SaaS companies come third, particularly those whose models make consequential decisions about credit, hiring, claims or clinical triage. Here the risk is not only commercial. A biased or unexplainable decision affecting Indian consumers creates legal and reputational exposure that no amount of model accuracy offsets.

How ISO 42001 Relates to What You Already Run

Because the structures align, an organisation holding ISO 27001 can extend its existing document control, internal audit and management review into the AIMS rather than duplicating them, which substantially reduces cost. The privacy dimension connects too: most AI systems run on personal data at some point, so DPDP obligations and ISO 27701 privacy management belong in the same conversation. Our guide to classification helps identify which training data carries the most sensitivity, and the privacy practice handles the obligations attached to it.

What Implementation Involves

The work starts with an inventory, because you cannot govern what you have not listed. Every AI system in use or development gets catalogued, including the third party tools teams adopted quietly, with its purpose, data sources, owner, users and affected stakeholders recorded. In most Indian IT organisations this step alone surfaces surprises: duplicate tools bought by different accounts, a model making customer facing decisions nobody formally approved, or client data flowing into a free service outside any contract.

An AI policy then sets the rules. What AI may be used for, what it may not, which tools are approved, what data may be entered into them, who approves new systems and where human review is non negotiable. Roles follow, so each significant system has an accountable owner and responsibilities between engineering, product, legal and security are clear.

Risk and impact assessment comes next and goes beyond conventional security questions. Could the model produce biased outcomes for particular groups? What happens when it is confidently wrong? Is the training data rightfully obtained? Can an affected person find out AI was involved and reach a human?

Controls are then implemented across the lifecycle: data sourcing and quality checks, documentation of models and datasets, validation before release, deployment approvals, monitoring for drift, incident handling for AI failures, supplier controls over third party models, and a defined retirement process. Internal audit, management review and the two stage certification audit close the loop. Organisations with an existing management system typically reach audit in four to six months; those starting cold should plan longer. An independent AI audit is the usual way to establish a baseline first.

Who Owns AI Governance Inside the Company

AI governance stalls when it belongs to everyone and therefore to no one. The standard expects top management to set direction, approve the policy and provide resources, but day to day ownership needs structure. Most Indian organisations that get this right form a small governance group drawing on engineering or data science, product or delivery, security, legal and the business units using AI most heavily. That group approves new systems, reviews impact assessments for higher risk uses, tracks incidents and reports to leadership.

Each significant system then has a named owner accountable for its purpose, performance and compliance. In services and BPO firms, account or delivery managers often own the AI tools deployed on client work, because they understand the client's contractual position and the effect on end customers. In product companies, product managers usually own AI features with engineering owning the model lifecycle.

Training matters as well, and it is routinely underestimated. Engineers need to know what data may be entered into which tools. Client facing staff need to know what they can say about AI involvement. Managers need to know when an impact assessment is required. A short, role specific briefing before the system goes live prevents most of the issues that would otherwise appear as audit findings.

Signs Your Organisation Should Start

Common Early Mistakes

Three patterns are already visible among early adopters. The first is scoping only the flagship model while ignoring the dozens of embedded AI features in software the company already licenses, which produces a system governing a fraction of reality. The second is writing a policy so restrictive that teams route around it, recreating the shadow adoption the system was meant to end. The third is treating impact assessment as a form to file rather than a decision tool, which auditors test by asking what a given assessment actually changed.

The remedy in each case is proportionality and genuine ownership, the same qualities that make any management system work.