Enterprise AI adoption stalls at the compliance gate, not the capability gate. The model usually works in the demo. What stops it from reaching production is that nobody can answer the compliance officer's questions: who is accountable when the output is wrong, what data went in, whether consent covered that use, and how you would reconstruct a decision six months later under audit. Capability gets you the pilot. Compliance decides whether the pilot ever becomes a system people rely on.
That gap is where most enterprise AI money quietly dies. Gartner predicted that at least 30 percent of generative AI projects would be abandoned after proof of concept by the end of 2025, citing poor data quality, inadequate risk controls, escalating cost, and unclear business value (Source: Gartner press release, 30 July 2024). The MIT NANDA study reported that 95 percent of enterprise generative AI pilots delivered no measurable profit-and-loss impact (Source: MIT NANDA, State of AI in Business 2025, reported by Fortune, 18 August 2025). Read those two numbers together and the pattern is clear. The problem is rarely that the model cannot do the task. The problem is that the surrounding accountability was never built, so the system cannot be trusted, deployed, or defended.
The demo is a capability test. Procurement is a liability test
An AI demo answers one question: can the system do the thing. That question is easy to pass now. Foundation models are good enough that a competent engineer can build a convincing prototype for most enterprise workflows in a few weeks.
Procurement asks a different set of questions, and they are the ones that kill deals. Who is liable when the output is wrong. What happens to the data. Can you prove what the system did on a specific date. Does this satisfy our obligations under DPDP 2023. What does the regulator expect us to have in place. None of these are capability questions. All of them are compliance questions, and a team that scoped only for capability has no answer.
This is why a pilot can look successful and still never ship. The engineering worked. The demo landed. Then it reached legal, compliance, and the data protection officer, and stopped, because the people who own risk were handed a system they could not sign off on.
In regulated industries the compliance gate is the whole gate
For a marketing team testing copy generation, compliance is a speed bump. For a hospital group, a pharma enterprise, a bank, or an insurer, compliance is the road. The buyer sits inside a framework of obligations that exist regardless of how good the model is, and the AI system has to fit that framework before it can touch a real workflow.
India's regulatory posture makes this concrete. There is no standalone AI statute. The MeitY India AI Governance Guidelines, published November 2025, take the position that existing law already applies to AI: DPDP 2023, the IT Act, consumer protection law, and sector regulators all bind AI systems today, and the guidelines prefer voluntary compliance and self-certification over a new enforcement regime (Source: MeitY, India AI Governance Guidelines, November 2025). That is not a lighter burden. It means an enterprise cannot wait for a dedicated AI law to tell it what to do. The obligations are live now, spread across statutes the compliance team already answers to, and the AI system inherits every one of them.
Under DPDP 2023 specifically, the enterprise deploying AI is the Data Fiduciary. It owns the consent, the purpose limitation, the breach notification duty, and the relationship with the Data Principal. A vendor cannot absorb that. So when a compliance officer looks at an AI proposal, they are not evaluating a product. They are evaluating whether their own organisation's obligations survive contact with the vendor's system. If the answer is unclear, the correct compliance decision is to say no, and that no is where the project dies.
Four questions that decide whether a project clears review
Across regulated deployments, the same four questions separate the systems that ship from the ones that stall.
Accountability. When the output is wrong, who carries it. This has to decompose by failure class rather than sit as one shared blob. In clinical settings, for example, clinical judgment stays with the clinician and vicariously with the hospital under Indian law, and no vendor contract moves it. System behaviour, an output outside its intended-use envelope, a record retrieved wrong, a data breach, sits with the vendor and belongs in writing as an accuracy threshold, an SLA, and a capped indemnity. Deployment, a site running the tool outside its stated envelope, sits with the operator. A vendor promising to indemnify away a liability it cannot legally hold is selling comfort, and a sharp compliance officer sees through it.
Data lineage and consent. What data trained or fed the system, and did consent cover this purpose. Purpose limitation under DPDP means consent obtained for one use does not automatically license another. A model fine-tuned on records collected for treatment, then repurposed for something the patient never agreed to, is a compliance defect no matter how well it performs.
Auditability. Can you reconstruct what the system did on a given date. None of the accountability allocation above is enforceable unless you can show what actually happened. That means audit logs, versioned models and prompts, and captured human overrides, running as standard rather than as a feature bolted on after an incident. The market gap here is wide. Walk into most enterprises with an incumbent AI vendor and ask to see the last thirty overrides, and there is usually no answer.
Human control. Where is the review step, and can the enterprise prove a human stayed accountable. In regulated work the answer is not full automation. It is a defined human review point that keeps a named person on the hook and gives the regulator a control to point at.
A system that answers all four clears review. A system that answers none is a demo, however impressive it looked.
Build the compliance layer first, not last
The common failure is sequencing. Teams build capability, prove it in a pilot, then treat compliance as a documentation exercise to be handled before launch. By then the architecture is fixed, and the controls a compliance officer needs, audit trails, versioning, override capture, purpose-scoped data handling, cannot be retrofitted without rebuilding. So the project stalls, and it joins the 30 percent abandoned after proof of concept.
The Principal Scientific Adviser's January 2026 white paper argued for embedding compliance into AI system design rather than layering it on afterward [verify], which is the right instinct and the opposite of how most pilots are run. Designing for the compliance officer's four questions from the first sprint costs more early and saves the entire project later, because the system arrives at review already answerable.
This is the thesis behind NextComply, Nextdot's compliance co-pilot for regulated industries, currently in paid pilots at a large hospital group and a large pharma enterprise. The bet is that in regulated sectors the compliance layer is not overhead on top of the AI system. It is the part that determines whether the AI system exists in production at all. Enterprise AI adoption is not a capability race any more. Capability is largely commoditised. The differentiator is whether you can put a system in front of a Chief Compliance Officer and have it survive the questions that matter.
Frequently asked questions
What actually stops enterprises from deploying AI?
Not model capability. Most enterprise AI pilots pass the technical demo. What stops deployment is the inability to answer risk and compliance questions: who is accountable for wrong outputs, what data was used and whether consent covered it, whether the system can be audited after the fact, and whether it satisfies obligations under laws like DPDP 2023. Gartner predicted at least 30 percent of generative AI projects would be abandoned after proof of concept by end of 2025 (Source: Gartner, 30 July 2024), and the causes were data quality, risk controls, and unclear value rather than raw capability.
Is compliance the real barrier to AI adoption?
In regulated industries, yes. For low-risk uses compliance is a minor step. For hospitals, pharma, banking, and insurance, the enterprise carries legal obligations that apply regardless of model quality, and the AI system must fit those obligations before it can touch a live workflow. A pilot that works technically but cannot clear legal, compliance, and the data protection officer never reaches production. That review, not the model, is the barrier.
What compliance issues block AI in regulated industries?
Four recur. Accountability, meaning a clear allocation of who is liable for each class of failure rather than one vague shared responsibility. Data lineage and consent, meaning proof that the data used was collected and consented for this purpose, which DPDP 2023 requires through purpose limitation. Auditability, meaning the ability to reconstruct what the system did on a specific date through audit logs, model and prompt versioning, and override capture. And human control, meaning a defined review step that keeps a named person accountable. A system that cannot address these does not clear review.
How do you get an AI project past compliance review?
Design for compliance from the first sprint instead of treating it as launch paperwork. Build audit logging, model and prompt versioning, and human override capture as standard. Scope data handling to the consented purpose under DPDP 2023. Write accountability down by failure class as accuracy thresholds, an SLA, and a capped indemnity, rather than promising blanket indemnity a vendor cannot legally hold. Keep a documented human review step. A system built to answer the compliance officer's questions from the start arrives at review already defensible, which is the difference between shipping and joining the abandoned pilots.