AI governance in an Indian organisation means three concrete things. Know what data your AI tools touch and whether that use is lawful under the DPDP Act, 2023. Keep a human accountable for any AI-assisted decision that affects a person's rights or opportunities. And check vendor claims before you trust them with your data. None of this requires a 40-page policy document on day one, just an owner, a short checklist, and a review cadence you actually follow.
What does "AI governance" mean in practice, not in theory?
Most AI governance content is written for regulators and philosophers. Practically, for an Indian organisation adopting AI tools in 2026, governance boils down to four questions you should be able to answer for every AI tool or workflow in use:
- What data goes into this tool, and did we have the right to use it that way?
- Who is accountable if the AI's output is wrong, biased, or harmful?
- Does anyone outside the organisation need to know AI was involved?
- What happens when (not if) something goes wrong?
If you can't answer these for your current AI usage, that's your starting point. Governance isn't a separate project bolted onto your AI adoption. It's the operating discipline that lets you scale AI use without scaling risk. If you haven't yet mapped out how AI adoption is even sequenced across your organisation, our AI Adoption Roadmap: A Practical Plan for Indian Organisations is a useful companion piece. Governance sits alongside that rollout, not after it.
What does the DPDP Act, 2023 actually require of AI users?
The Digital Personal Data Protection Act, 2023 (DPDP Act) is India's core data protection law, and it applies to any organisation processing personal data of individuals in India, regardless of whether you've built a formal "AI policy." Feeding customer data, employee data, or citizen data into an AI tool is a form of processing, and the Act's obligations attach to that processing itself.
In plain terms, here's what matters for AI use:
- Consent and notice: If you're using personal data (customer records, resumes, chat transcripts, health information, etc.) as input to an AI system, you generally need a lawful basis to process it, typically informed consent, given for a specific, stated purpose. A vague "we may use your data to improve our services" notice is weak ground if you're now feeding that data into a large language model for a use case the person never agreed to.
- Purpose limitation: Data collected for one purpose (say, processing a job application) shouldn't be repurposed to train or fine-tune an AI model without a fresh basis for that new purpose. This is the most commonly violated principle when teams get excited about "let's use our historical data to build a model."
- Data minimisation: Don't feed AI tools more personal data than the task needs. If a summarisation tool only needs the body of a support ticket, don't also pipe in the customer's full account history "just in case."
- Breach notification: If personal data processed by an AI tool (yours or a vendor's) is compromised, the Act requires you to notify the Data Protection Board and affected individuals. This obligation exists whether the breach happened in your own systems or in a third-party AI vendor's, which is exactly why vendor due diligence (below) matters.
We're deliberately not citing specific section numbers here. The DPDP Act's rules are still being operationalised through subordinate rules and Data Protection Board guidance, and precision on section references is less useful to you than getting the practical obligations right. Treat this as a starting map, not a legal opinion, and get counsel involved before you finalise policy language.
What is human-in-the-loop and when is it mandatory?
Human-in-the-loop (HITL, i.e. keeping a human reviewer in the decision path) is the single most important governance control for AI-assisted decisions. An AI system can recommend, draft, flag, or score, but a human with real authority to override the output makes the final call, especially where the decision affects someone's access to a job, loan, service, or benefit.
You need HITL, at minimum, for decisions that are:
- Consequential to an individual: hiring, credit, insurance, admissions, disciplinary action, benefit eligibility.
- Irreversible or hard to reverse: terminations, legal filings, financial transactions, public communications.
- High-stakes on volume: even low-risk-per-instance decisions become high-stakes in aggregate (e.g. an AI triage tool routing thousands of citizen grievances).
Where HITL is less critical: internal drafting, first-pass research, formatting, and other low-stakes assistive use where a human reviews the output anyway before it goes anywhere. The mistake most organisations make isn't skipping human review everywhere. It's assuming that a human "in the loop" who rubber-stamps AI output without real scrutiny counts as governance. It doesn't. If your reviewers approve 98% of AI recommendations without pushback, that's a sign the review is theatre, not oversight. For a worked example of what HITL and governance look like when applied to one sector specifically, see AI for Public Administration, where the stakes of automated decision-making are especially visible.
How do you check for bias and fairness in AI-assisted decisions?
Bias in AI outputs isn't a hypothetical risk you address by writing a values statement. It shows up concretely: a resume-screening tool that downgrades candidates from certain colleges or with career gaps, a credit-scoring assistant that correlates with pin codes that proxy for caste or religion, a customer service AI that responds differently based on the language or dialect used.
Practical steps that actually catch this:
- Test with representative samples before rollout. Run the tool against real, diverse historical cases and check whether outcomes differ systematically across gender, region, language, or other sensitive groupings.
- Audit outputs periodically, not just at launch. Models and prompts drift, vendors update underlying models silently, and edge cases accumulate. A quarterly sample review is a reasonable baseline for anything consequential.
- Give people a way to contest an AI-influenced decision. An appeal path that routes to a human is both a fairness safeguard and, often, a legal expectation.
- Document what you tested and what you found. "We assumed it was fine" is not a defensible position if a decision is later challenged.
None of this requires a data science team. It requires someone with the authority to pause a rollout if the numbers look wrong, and the discipline to actually look.
When do you need to disclose that AI was involved?
Transparency doesn't mean stamping "AI-generated" on everything. It means disclosing AI involvement where it changes how a reasonable person would interpret or trust the output: customer-facing chatbots that could be mistaken for a human agent, AI-assisted decisions that affect someone's application or eligibility, AI-generated content presented as original human analysis or testimony, and AI-driven pricing or recommendation systems where disclosure builds trust rather than eroding it.
You generally don't need to disclose AI use for internal drafting, research assistance, or formatting where a human reviews and owns the final output. That's just a tool, the same way spellcheck is a tool. The test is simple: would the person on the other end feel misled if they found out later? If yes, disclose upfront.
What should you check before adopting a third-party AI tool?
Most organisations don't build their own models. They adopt SaaS AI tools, and the governance risk mostly lives in that vendor relationship. Before signing up, check:
- Where is data processed and stored? Cross-border data flow matters under the DPDP Act and for sector-specific regulations (RBI for financial data, for instance).
- Is your data used to train the vendor's models? Many free or lower tiers of AI tools use customer inputs for training by default. Check the actual settings, not just the marketing page. Enterprise tiers usually have an opt-out, but you have to turn it on.
- What's the data retention and deletion policy? Can you get your data deleted on request, and how long does that take?
- Does the vendor have real certifications, not just claims? "Enterprise-grade security" on a landing page means nothing without something to verify. Ask for SOC 2, ISO 27001, or equivalent documentation, and actually read the summary rather than filing it away unopened.
- What happens on a breach? Does the contract obligate the vendor to notify you within a timeframe that lets you meet your own DPDP breach-notification obligations?
- Can you exit cleanly? Data portability and deletion on contract termination should be spelled out, not assumed.
This is exactly the kind of judgment call that a "learn 50 AI tools in a weekend" webinar doesn't prepare you for. Knowing which tool has the flashiest demo tells you nothing about whether it's safe to plug into your HR or finance data. We've written more on why 50-AI-tools courses don't work. Governance is a judgment skill, not a tool inventory.
A simple governance framework you can adapt
You don't need a 40-page policy to start. You need clear ownership and a short set of rules everyone can actually remember.
| Governance area | Practical requirement | Who owns it in most organisations |
|---|---|---|
| Data handling (DPDP compliance) | Map what personal data flows into which AI tools; confirm lawful basis and purpose limitation | Data protection officer / compliance lead, with IT |
| Bias and fairness testing | Test consequential AI decisions against diverse samples before and after rollout | Function head using the tool (HR, credit, admissions), with a technical reviewer |
| Transparency and disclosure | Disclose AI involvement wherever it would change how someone interprets the interaction | Product/communications lead |
| Human-in-the-loop | Named human reviewer with real override authority for consequential decisions | Department manager accountable for the outcome |
| Vendor due diligence | Checklist review (data residency, training use, certifications, breach terms) before any new AI tool is adopted | Procurement/IT, with legal sign-off for consequential tools |
| Incident response | Defined process for what happens when an AI output causes harm or a breach occurs | Compliance lead, with executive escalation path |
Assign each row to a real person, set a review cadence (quarterly is reasonable for most mid-sized organisations), and revisit the table whenever you adopt a new AI tool or expand an existing one into a new use case.
Honest limits
- AI governance isn't a compliance checkbox exercise. It needs a real owner and a review cadence, not a policy document that gets written once and never revisited.
- The DPDP Act's obligations apply to your organisation whether or not you've built a formal AI policy. The law doesn't wait for you to be ready.
- Bias in AI-assisted decisions needs active testing, not just good intentions. "We designed it to be fair" is not evidence of fairness.
- Vendor claims about "enterprise-grade security" need actual verification, not just trust. Ask for the certificate, not the tagline.
Where to build these skills
Understanding governance isn't something you pick up from a tool-list webinar. It's a judgment skill built through structured, applied learning. Garage Labs Tech has trained 150,000+ professionals across 17+ countries, with a 49,000+ member community, and runs programmes in collaboration with IIT Delhi, IIM Lucknow, Masters' Union, and the Harvard Business School Alumni Association.
If you're starting from the basics of applied AI use in an organisational context, AI Fluency is a 6-week live, no-code programme (₹32,000+GST, roughly ₹37,760) that covers responsible, practical AI adoption. If you're further along and want your team to actually build and govern AI workflows, including agents that touch real data, the Applied AI Accelerator Bootcamp is a 10-week live programme (no prior tech background needed) (₹75,000+GST, roughly ₹88,500) where participants ship 7 to 10 AI agents, including RAG (Retrieval-Augmented Generation) pipelines, culminating in a Demo Day. Not sure where you stand? Take the free AI readiness quiz first.
Frequently asked questions
Does a small organisation need a formal AI governance policy?
You need clear ownership and a short checklist more than you need a formal document. A one-page table assigning who owns data handling, bias checks, and vendor vetting is more useful early on than a lengthy policy nobody reads. Formalise it as your AI use scales.
Does the DPDP Act apply if we only use AI tools internally, not customer-facing?
Yes, if the data involved is personal data, including employee data. The DPDP Act applies to the processing of personal data of individuals in India regardless of whether the AI use is internal or customer-facing.
Who should own AI governance inside an organisation?
There's no single universal answer, but it should be a named individual, not a committee with diffuse responsibility. Typically that's a compliance or data protection lead, working with IT and the business function heads who actually use the AI tools day to day.
How often should we re-test an AI tool for bias?
For consequential decisions (hiring, credit, admissions), quarterly review of outcomes is a reasonable baseline, with an additional check any time the underlying model or vendor changes. Low-stakes internal use needs far less frequent review.
What's the single biggest governance mistake organisations make?
Treating human-in-the-loop as a checkbox rather than real oversight: having a person technically "review" AI output without giving them the time, authority, or incentive to actually push back on it.
For a broader view of how governance fits into your overall AI rollout, browse our programmes or take the free AI readiness quiz to see where to start.