Four AI use cases suit an Indian plant today: visual inspection, predictive maintenance, demand forecasting and document reading. Each works when three things are true. The data exists in usable form, the model is judged against a plain baseline, and a person stays in charge of the final call. This guide gives the data each one needs and the usual reason it fails.
Last reviewed 8 November 2026 against the sources listed at the end.
The four use cases at a glance
The failure reasons below are general engineering observations, not measured rates.
|
Use case |
What it does |
Data it needs |
Usual reason it fails |
Cheapest first test |
|---|---|---|---|---|
|
Visual inspection |
Flags defects on parts or surfaces from camera images |
Images of good and bad parts from the real line, labelled by your inspectors |
Lighting and camera angle differ from the training photos |
A feasibility run on footage from your own line |
|
Predictive maintenance |
Warns that a machine is drifting before it stops |
Sensor readings plus a dated record of every real failure and repair |
Failures are too few, or the repair log is unreliable |
Check how many failures your history holds per machine type |
|
Demand forecasting |
Predicts orders by product and period |
Two or more years of orders by product, with price and promotion changes |
The forecast does not beat last year's figure |
Compare against a simple baseline on held-back months |
|
Document AI |
Reads invoices, challans, test certificates and gate slips |
A sample of real documents in every format you receive |
Scans and handwriting on site documents |
Run a batch of your own documents and count the corrections |
Visual inspection
A camera and a model check each part. The model returns a decision and a confidence score. Low-confidence parts go to a person.
Data needed. Photographs from your own line, taken with the camera, lens and light you will deploy. Good parts, and each defect type, labelled by the inspectors who know the standard. Rare defects need the most care, because a model cannot learn what it has seen only a few times.
What breaks it. Light. A shop-floor window, a changed lamp or a dusty lens shifts the images enough to lower accuracy. Plan the camera and lighting design as part of the project, not as an afterthought.
What to demand. Accuracy reported by defect class, not one overall figure. A model that is right on common scratches and blind to rare cracks shows a good average. Confidence scores are not guarantees, so decide which parts a person always rechecks.
Who owns the data. The labelled image set should belong to you. It is the asset that lets you change vendors or retrain later.
Predictive maintenance
The model watches readings such as vibration, temperature and motor current, and raises an alert when a machine's pattern moves away from its normal one.
Data needed. Sensor readings over time, plus the dated history of real failures and repairs on the same machine. Without the repair log, you have signals and no answers.
Where the readings come from. Where a plant runs SCADA or PLC systems, the readings can come from them. In Brihat integrations, SCADA and PLC data flows out of the plant in one direction, with no write-back to the control system. That keeps the model advisory. It cannot start or stop a machine.
What breaks it. Too few failures. A well-maintained machine fails rarely, so there is little to learn from. In that case, start with anomaly detection on normal behaviour, and treat each alert as a prompt to inspect.
Where standards help. According to ISO's catalogue, ISO 13374 gives guidelines for processing, communicating and presenting machine condition-monitoring data, and ISO 17359 gives general guidelines for condition monitoring. Use them to decide what to measure and how to hand alerts to maintenance.
Demand forecasting
A forecast of orders by product and period feeds production plans and purchase orders.
Data needed. Orders by product, customer group and date for at least two full years, so the model sees every season and festival. Add price changes, promotions, stock-outs (an unmet order is demand too) and any one-off bulk order flagged as such.
What breaks it. Dirty history. A stock-out that looks like low demand teaches the model the wrong lesson. Clean master data matters as much here as in an ERP move; see ERP data migration: the master data decides the timeline.
What to demand. A model that beats a baseline. The baseline can be as plain as the same month last year. If the model cannot beat it on months it has not seen, do not run it.
Use it where a decision changes. A forecast that no purchasing or planning person acts on is a report. Tie it to a decision: raw-material orders, shift plans, or finished-goods stock levels.
Document AI
Software reads supplier invoices, delivery challans, weighbridge slips and test certificates, and fills your ERP fields. A person checks what the software is unsure about.
Data needed. A sample of real documents in every layout you receive, including poor scans, stamps and handwriting.
The Indian advantage: e-invoices. Since 1 August 2023, businesses above the aggregate-turnover limit set by the e-invoicing notification must report B2B invoices to the GST e-invoice system, per the portal's own pages. The system returns a 64-character Invoice Reference Number (IRN) and a QR code inside signed data, and a GST invoice is valid only with a valid IRN. For an invoice from such a supplier, a document reader can start from the QR code, which is machine-readable, and use text recognition only for fields the QR does not carry. A figure the reader extracts can then be compared with the signed one. The check is simple, and it catches misreads on the fields that matter most: supplier, number, date and value.
Where it is harder. Suppliers below the threshold, delivery challans, weighbridge slips and handwritten gate slips carry no signed data. Expect more corrections there, and route them to a person.
What breaks it. Layout drift. A supplier changes the invoice format and extraction quietly gets worse. Measure the share of fields people correct each week. A rising share is your early warning.
For routing uncertain reads to a person, see human-in-the-loop design people accept. For GST at volume, see GST, e-invoicing and e-way bills at real volume.
Choosing the first project
Start with the use case where three answers are yes.
- Does a decision change? Someone will reject a part, plan a repair, order material or post an entry differently because of the output.
- Does the data exist today? Not "could be collected": already stored, dated and traceable to a machine, product or document.
- Can you measure the result in your own numbers? Rejections, downtime hours, stock-outs, hours spent on entry.
A use case with one "no" is a data project first. Fix that gap, then return to the model. The first deliverable can be a clean repair log or a labelled image set. Either will serve every later model you build.
Four checks before any model goes live
- Baseline first. Write down what the current process achieves: defect escapes, unplanned downtime hours, forecast error, document handling time. A model is only better than something you measured.
- Test on data the model has not seen. Hold back recent months, other shifts or another supplier. The Brihat guide on building the evaluation set before the system covers how.
- Name the human. For each alert or flag, decide who acts, within what time, and what they do when the model is wrong.
- Plan the drift. Lines, suppliers and seasons change. Someone must watch accuracy monthly and own a retraining step.
Cameras, people and the law
A camera that watches a part is a quality tool. A camera that also records workers is personal data processing under the DPDP Act, 2023. The Act lets an employer process employees' data for employment purposes or to safeguard the employer from loss or liability. It does not remove the duty to keep the data safe and to erase it when the purpose ends (section 8). Point inspection cameras at the part, and restrict any recording of people to the safety purpose you have written down. See the DPDP Act and AI systems.
On AI more broadly, India's AI Governance Guidelines (MeitY, 5 November 2025) are guidance, not a statute. According to PIB's summary, the guidelines rely on existing law and sector regulators, and they say a new AI law is not needed at this stage. Keep a person in the final decision for anything that affects people. Read AI governance for regulated Indian enterprises for a working checklist.
Where Brihat fits
Brihat Infotech's computer vision and speech work starts with a feasibility run on your real footage, and the labelled dataset belongs to you. Start a conversation.
Sources and primary texts
- Digital Personal Data Protection Act, 2023, section 7 (MeitY, PDF)
- India AI Governance Guidelines, MeitY press release, 5 November 2025 (PIB)
- ISO 13374-1:2003, Condition monitoring and diagnostics of machines: data processing, communication and presentation
- ISO/TC 108/SC 5 catalogue, listing ISO 17359:2018
- GST e-invoice system: e-invoicing mandate
- GST e-invoice system: IRN