An AI strategy your board and engineers both believe

Most AI strategy documents fail the same test: an engineering lead reads them and cannot start anything on Monday. They identify themes rather than initiatives, assert value without a model, ignore data readiness, and name no owner. They are not wrong, exactly — they are unactionable, which is worse because it is harder to argue with.

A usable strategy is specific to the point of discomfort. Not "apply AI to customer service" but "deflect the six highest-volume ticket categories with a grounded assistant, ~₹2.1 crore annual handling cost addressed, data is ready, owner is the Head of Support, ship in Q2, success is 45% deflection at CSAT parity". That sentence can be argued with, budgeted, assigned and measured. The thematic version cannot.

It is also explicit about what not to do. Every discovery we run produces a list of initiatives we recommend against — usually because the data is not there, the process changes too often to encode, the regulatory exposure outweighs the benefit, or a non-AI fix would deliver most of the value for a tenth of the cost. Clients frequently tell us this list saved them more than the recommendations did.

Finally, it survives being read by the people who must implement it. We present to the executive team and to the engineers in the same week, and if the engineers do not believe the estimates, the estimates are wrong.

Value and feasibility are scored independently, because conflating them is how portfolios end up full of feasible irrelevance or valuable impossibility.

Value has three components. Annual cost or revenue at stake, calculated from real volumes and fully loaded costs rather than headline salary figures. Strategic weight, reflecting whether the initiative supports something the organisation has already committed to. And measurability — an initiative whose success cannot be observed will not survive its first budget review regardless of its actual impact.

Feasibility has four. Data readiness, assessed by inspecting samples rather than asking whether data exists; this is where most optimistic estimates die, and finding out during discovery is far cheaper than during a build. Integration complexity, driven by how many systems must be touched and whether they have APIs. Regulatory exposure, particularly where decisions affect individuals. And organisational readiness — whether a named owner exists and whether the affected team has been consulted or merely informed.

The two scores produce a matrix, and the sequence follows from it: high value and high feasibility first, high value and low feasibility next but preceded by whatever raises feasibility, and low value initiatives declined regardless of how straightforward they are. It sounds obvious written down. It is rarely done, which is why AI portfolios so often begin with the easiest thing rather than the most valuable feasible thing.

The question is asked as though it were binary and it is usually three-way, with the right answer varying per initiative rather than per organisation.

Buy when the capability is genuinely commoditised and not a differentiator: transcription, translation, generic document OCR, standard support-desk assist. Buying is faster, the vendor absorbs the maintenance, and building a slightly better version of a commodity is a poor use of an engineering team. The trap is buying a platform that promises to cover everything and delivers 70% of each thing, which is how organisations end up with a licence and a services bill.

Build when the capability encodes something specific to you — your domain knowledge, your process, your data — or when it is close enough to your differentiation that owning it matters. Build also wins on unit economics at volume, and on avoiding the integration debt that accumulates when each vendor owns a piece of your workflow.

Partner when you need to build but the capability is not one you want to sustain internally. This is the honest category most consultancies skip because it implies their client should not hire — but a specialist team building a system your engineers then own is frequently the right answer, and we say so including when the partner is not us.

Whichever the recommendation, it carries a five-year total cost comparison including maintenance, integration, licence escalation and the cost of switching. Build-versus-buy decisions made on year-one cost alone are wrong roughly half the time.

AI governance fails in two directions. Too light, and shadow AI proliferates with customer data in consumer tools. Too heavy, and every use case queues behind a committee that meets monthly, which produces the same shadow AI for a different reason.

The framework we build is risk-tiered. Low-risk internal uses — drafting, summarising internal content, code assistance — operate under a clear usage policy with no approval needed. Medium-risk uses touching customer data or external communication require a lightweight documented review against a checklist, typically days rather than weeks. High-risk uses affecting decisions about people — hiring, credit, insurance, clinical, disciplinary — require formal review, documented human oversight, bias assessment and sign-off.

Tiering is what makes governance survivable. Most AI usage in most organisations is low-risk, and routing it through a heavyweight process teaches everyone that the process is an obstacle to be avoided. Concentrating rigour where consequences are real is both safer and more likely to be followed.

The framework includes a usage policy written for employees rather than lawyers, an approval workflow with a named owner and a service-level commitment, a model registry recording what is in use and for what, model risk management proportionate to tier, and an incident process for when an AI system produces a harmful or incorrect output. We map each element to the regulatory obligations that apply to you, so the framework does double duty as compliance evidence.

The EU AI Act applies to organisations placing AI systems on the EU market or whose output is used in the EU, regardless of where they are established — which catches a great many Indian and global companies that assume it does not. Obligations are tiered by risk classification, and the practical work for most enterprises is establishing which of their systems fall into the high-risk category and building the technical documentation, logging, human oversight and post-market monitoring those systems require.

Transparency obligations are broader and catch more organisations: systems interacting with people must disclose that they are AI, and synthetic content must be marked. This applies to chatbots and voice agents that many companies do not think of as regulated AI at all.

India’s Digital Personal Data Protection Act governs the personal data flowing through AI systems, with consent, purpose limitation and data-principal rights that constrain what training and processing is permissible. Sector regulators — RBI, IRDAI, and health authorities — layer additional requirements on model use in decisions affecting customers, and these tend to move faster than the general framework.

Our regulatory work is deliberately practical: classify each existing and planned system, identify the specific obligations that follow, map them to owners with deadlines, and design the technical evidence to be generated as a by-product of the system rather than assembled by hand before an audit. Organisations that build this into the architecture — versioned processes, complete run records, documented oversight points — find compliance close to free. Those that retrofit it spend quarters.