How to Choose an AI Consulting Firm in India: 12 Checks

The slide deck always looks the same. The twelve questions below are how you find out what happens after it. We wrote this checklist the way we would want to be evaluated ourselves, and the honest news for buyers is that most firms will fail several of these checks. That is the point of asking.

Why AI consulting selection fails

Selection fails because the buying conversation and the delivery reality are different events, separated by months. In the buying conversation, every firm has impressive demos, confident architects and a methodology slide. By the time delivery reveals what the firm actually is, the contract is signed and the switching cost is real.

The graveyard this produces is well documented. We analysed the pattern in why 95% of enterprise AI pilots fail, and a recurring thread runs through it: pilots that die in decks. Projects that produce a proof of concept, a presentation, an invoice, and nothing that any employee uses six months later.

The defence is to evaluate an AI firm the way your procurement team would evaluate any serious supplier. Not on vision. On evidence, checkable before signature. Twelve checks follow, grouped into four blocks. Each comes with what to ask and what a good answer sounds like.

The 12-point checklist

Block one: Proof

1. Production systems live today. Ask: which of your AI systems are running in production right now, inside a client's daily operations? A good answer names specific systems in use this week, describes who uses them and for what, and distinguishes clearly between production deployments and pilots. A weak answer talks about capabilities, accelerators and frameworks without ever landing on a system a real employee touched this morning.

2. Named references. Ask: can we speak to clients running your work in production? A good answer is a yes with contactable references, offered without theatrical reluctance. Some clients legitimately cannot be named, non-disclosure terms in sectors like pharma are real, and a serious firm will say so plainly while still producing references from clients who can speak. A weak answer is a logo wall nobody is allowed to call.

3. Measured outcomes. Ask: for one production system, what changed, measured how? A good answer states the before, the after, and how the number was captured. It also admits what did not improve, because honest measurement always finds some of that. A weak answer offers only adjectives, or figures so round and so universal that no actual measurement could have produced them.

Block two: Integration depth

4. Works inside your existing systems. Ask: our operation runs on a specific ERP and CRM; show us work delivered inside systems like ours. The valuable form of AI consulting delivers intelligence into the software your team already uses, which is the discipline behind our AI development and automation practice. A good answer engages with your actual stack. A weak answer pivots to proposing a new platform before understanding the one you have.

5. MCP capability. Ask: how do you connect AI to existing software, and what role does the Model Context Protocol play in your approach? MCP has become the open standard for wiring AI into live systems, and a firm working at the integration frontier should discuss it concretely: what they have connected with it, what its limits are. A weak answer has not heard of it, or badges every integration question with a proprietary connector pitch.

6. Data access patterns. Ask: how will you read our data, and what happens to it in flight? A good answer describes specifics: where queries run, what gets retrieved versus what gets sent to a model, how retrieval is scoped to what each user may see. Firms that build serious retrieval systems, the kind described on our enterprise RAG page, can answer this at whiteboard depth without preparation. A weak answer waves at the word secure and moves on.

Block three: Governance

7. Who owns the code and the prompts. Ask: at the end of the engagement, who owns what was built, including the prompts and configurations? The answer that protects you is ownership terms agreed in writing before work starts. Be wary of blanket verbal assurances in either direction; what matters is the written agreement, settled before the first sprint, not negotiated after delivery when leverage has shifted. Our own position on this is published on our trust page.

8. Data residency. Ask: where does our data physically live and process during the engagement? A good answer names locations and offers choices where regulation or policy demands them. A weak answer does not know, which means nobody checked, which tells you how the rest of the engagement will handle details that matter.

9. Sub-processors. Ask: which third parties will touch our data, including model providers, hosting and any subcontracted work? A good answer is a written list, with a commitment to notify you before it changes. Every AI build involves third-party services somewhere. The question is whether the firm tracks that honestly or discovers its own supply chain when you ask.

Block four: Engagement

10. Fixed scope first step. Ask: what is the smallest complete engagement we can start with? A good answer proposes a bounded first step with a defined deliverable, an assessment or a single working integration, structured so you can judge the firm on delivered work before committing wider. A weak answer opens with a large multi-phase programme and treats a small start as beneath the relationship.

11. Exit terms. Ask: if we end this engagement, what do we walk away with and how does handover work? A good answer describes the package: code, documentation, credentials, deployment knowledge, in a form another team could pick up. Firms confident in their delivery make leaving easy, because they expect you to stay for the work, and the paradox is reliable in both directions.

12. Who maintains it. Ask: after go-live, who keeps this running, and what does that arrangement look like? A good answer offers choices, including training your own team to operate what was built, and describes how changes are handled after handover. A weak answer is silent on maintenance entirely, which usually means the firm's business model ends at delivery and your system's life begins there.

Put all twelve to every firm on your shortlist and keep notes. The published way a firm engages, like our own how we work page, should match what its people say in the room. Divergence between the two is itself a finding.

Accucia's view

An AI consulting firm should be evaluated like any supplier of critical equipment: on production evidence, integration depth, written governance and clean exit terms. Accucia Softwares Pvt. Ltd. publishes its positions on these checks because we clear them, and because a market where buyers ask harder questions is a market that stops funding deck-ware. We were founded in Pune in 2018 by Mr. Sumeet Katariya, and the software projects delivered since 2018 have taught us that the firms worth hiring welcome this checklist. Run it on us. Run it on everyone you shortlist.

Start with a free AI Readiness Assessment and judge us on the output. WhatsApp: https://wa.link/1bwdd2

FAQ

What does an AI consulting firm actually do?

A genuine AI consulting firm assesses your systems and data, identifies which processes can be automated or augmented, then designs and builds working software that runs inside your operations. The output should be systems your employees use daily, not reports and presentations about what could theoretically be built.

How do I verify an AI consulting firm's claims?

Ask for production systems you can see demonstrated live, references you can actually call, and measured outcomes with the measurement method explained. Check that written answers on code ownership, data residency and sub-processors exist before signing. Firms with real delivery history can satisfy all of this quickly.

Should we choose a large firm or a specialist for AI consulting?

Size matters less than evidence. Apply the same twelve checks to both: production proof, integration depth into your specific ERP or CRM, written governance terms and a small bounded first engagement. The firm that passes them, whatever its headcount, is safer than a famous name that will not start small.

Who should own the code an AI consulting firm builds?

Ownership should be settled in writing before work starts, covering the code, the prompts and the configurations. Insist on seeing those terms during evaluation rather than after delivery. The negotiating moment is before signature, and a firm that resists written clarity at that stage is answering your question.

What is a reasonable first engagement with an AI consulting firm?

A bounded piece of work with a defined deliverable, such as a readiness assessment of your systems or one working integration into your existing software. It should be small enough to judge the firm on completed delivery, and structured so the output remains useful even if you go no further.