AI Governance for Indian Companies: Inventory, Risk Tiers, Human Review and Incident Logs
A company cannot govern AI that it has not inventoried. Employees may be using public models, vendors may embed AI into software and business teams may deploy automated decisions without calling them AI. The first governance deliverable is therefore a complete use-case and model register—not a high-level ethics statement.
Finin2min Summary
- Inventory internal, vendor-embedded and employee-initiated AI use cases.
- Classify risk by impact on money, rights, safety, compliance, reputation and data sensitivity.
- Apply stronger testing and human oversight as impact increases.
- Record data sources, model version, limitations, approvals and incidents.
- Create a controlled retirement process when models drift, vendors change or use cases end.
India's policy direction emphasises safe and trusted AI while encouraging innovation. For companies, practical governance means linking each use case to an accountable business owner, technical owner, data owner and control reviewer. The framework should be proportionate: an internal meeting-summary tool is not governed like a credit decision, fraud alert or automated hiring screen.
Create a useful AI register
Record the use case, decision affected, users, model and vendor, deployment location, data categories, outputs, human reviewer, performance metric, approval date and next review. Include shadow use discovered through surveys, browser controls, expense claims and procurement records. A register that lists only projects owned by the technology team will miss the largest operational risk.
Use impact-based risk tiers
Low-risk tools may need approved access and basic output checking. Medium-risk tools may require testing, source traceability and periodic monitoring. High-impact use cases affecting payments, customer eligibility, employment, compliance reporting or sensitive data need formal approval, bias and error testing, human override, incident escalation and often legal review. Prohibited uses should be stated explicitly.
Test for the failure mode that matters
Generic model benchmarks are insufficient. A tax assistant should be tested on current law, ambiguous facts and citation accuracy. A collections model should be tested for unfair treatment and escalation errors. A document extractor should be tested on poor scans and unusual formats. Validation sets should represent the real population and include stress cases, not only demonstration examples.
Monitor, record and retire
Performance can change when data, prompts, model versions or business processes change. Monitor accuracy, overrides, complaints, security events and unusual output. Incident logs should capture impact, containment, root cause and remediation. When a use case no longer meets its threshold, access should be suspended and data or integrations retired in a controlled manner.
What the Viral Version Usually Misses
Many governance posts offer abstract principles—fairness, transparency and accountability—without saying who approves a use case or what evidence proves compliance. Principles matter, but boards need an operating system: thresholds, owners, tests, logs, exceptions and escalation. Conversely, governance should not require the same paperwork for every harmless productivity tool; excessive uniformity drives use underground.
Worked Scenario: Risk-tiering four AI use cases
A company classifies meeting transcription as low risk, invoice-field extraction as medium risk, vendor fraud scoring as high risk and autonomous payment release as prohibited. The extraction tool may operate with sample validation and an exception queue. Fraud scoring needs documented factors, false-positive monitoring and human investigation. Payment release remains outside permitted AI authority. The framework allows useful automation while reserving the strongest controls for financial impact.
Practical Decision Checklist
- Survey and discover AI use across functions and vendors.
- Assign business, technical, data and control owners.
- Define low, medium, high and prohibited tiers.
- Test each use case against its real failure modes.
- Monitor overrides, complaints, drift and incidents.
- Review the register with senior management and the board periodically.
Article-Specific Q&A
Does every AI use case require board approval?
No. The board should approve policy, risk appetite and oversight for material use cases. Lower-risk tools can follow delegated approval within the framework.
How should embedded AI in software be governed?
Include it in the register, understand what data it uses and decisions it influences, obtain vendor information and apply the same impact-based assessment as an internally built model.
Is human review always required?
The level depends on impact and reversibility. High-impact or uncertain outputs need meaningful review; low-risk drafting may only need normal user checking.
What is an AI incident?
Examples include material incorrect decisions, leakage of confidential data, discriminatory outcomes, unauthorised actions, security compromise or sustained performance below the approved threshold.
Can a company rely on the vendor's model card?
It is useful input but not a substitute for use-case-specific testing, contract review and monitoring in the company's own environment.
How often should the AI register be reviewed?
At least quarterly for active material use cases and whenever a model, vendor, data source, prompt, integration or business purpose materially changes.
Sources and Verification Trail
- MeitY — India AI Governance Guidelines: Official Indian policy and governance material. — https://www.meity.gov.in/
- IndiaAI — Safe & Trusted AI: Official mission pillar and responsible-AI initiatives. — https://indiaai.gov.in/
- NIST AI Risk Management Framework: Primary framework for govern, map, measure and manage practices. — https://www.nist.gov/itl/ai-risk-management-framework
- Digital Personal Data Protection Framework: Official privacy framework relevant to personal data used by AI. — https://www.meity.gov.in/data-protection-framework