Practical notes from the engineers who build agents, copilots and AI products.
AI copilot development fails for five recurring reasons: the copilot does jobs users never asked for, it cannot see the customer's own data, it answers but cannot act, nobody built an eval suite, and nothing is measured after launch. Each is a decision made early, and each has a specific fix.
AI copilot development for startups and for enterprises differs on five axes: scope, governance, integration depth, compliance and timeline. The engineering core is the same in both. What changes is how many jobs ship at once, how many approvals sit around each action, and how long security review takes.
Measure an AI copilot on four levels: offline eval pass rate, task completion in production, weekly repeat use by the same people, and the business number the copilot was meant to move. Message volume and satisfaction scores are the two metrics that mislead most often.
A copilot is compliant with the DPDP Act when it processes personal data for a purpose the user consented to, keeps it no longer than needed, respects access rights inside retrieval, and leaves an audit trail. The Act sets obligations on you as data fiduciary, not on the model vendor.
Machine learning development services projects fail for five repeatable reasons: an undefined target variable, leaked training data, a model never wired into a decision, no owner after handover, and success measured as aggregate accuracy rather than business outcome. None of the five is a modelling problem.
The modelling work barely changes. What changes is everything around it: a startup optimises for one decision, one data source and a ten-week path to evidence, while an enterprise optimises for governance, integration across systems of record and model risk review. Startups buy speed; enterprises buy defensibility.
No machine learning service is compliant in itself. The DPDP Act binds you as the data fiduciary, so compliance is a property of the system you build: lawful basis for training, a mapped data path, retention that survives erasure requests, and logs an auditor can read.
Measure at four levels: model quality on a held-out set, system behaviour in production, the business decision the model changed, and the cost of running it. A project reporting only the first level is reporting a laboratory result, not a working system.
You implement RAG in five phases: write the question set the system must answer, build ingestion and chunking, build hybrid retrieval with reranking, ground generation in citations, then measure and roll out behind a flag. Evaluation is phase one, not the last phase, and the question set is the contract.