AI in industry
AI Readiness in Industry: Is Your Process Ready?
Six criteria for a sound AI pilot
Contents
- When is a process ready for AI?
- The AI readiness assessment
- Scoring
- Suitable industrial use cases
- A complaint-handling pilot
- Moving from test to operation
- Law, security and responsibility
- Sources
When is a process ready for AI?
A process is ready for an AI pilot when its goal is measurable, suitable data is accessible and subject-matter experts can check whether the result is correct. Interfaces must be controllable. Errors need a safe recovery path and a named owner.
AI readiness always applies to one use case. Data volume alone says little. Thousands of unstructured PDFs can be less useful than a few hundred well-classified cases. What matters is whether the data represents the real process and whether experts can recognise errors.
The pilot does not need to automate the complete process. A narrow assistance step is often the better start. AI can read documents and prepare a suggestion while a person checks it and remains responsible for the decision.
The AI readiness assessment
Score each criterion with zero, one or two points:
- 0 points: The requirement is missing or unknown.
- 1 point: It is partly met, with one concrete gap remaining.
- 2 points: Data, responsibilities or a test demonstrate that it is met.
1. Process and goal
The process has a clear beginning and end. Volume, processing time, error rate or another baseline is known. The pilot should improve one named metric.
“We want to use AI” scores zero. “We want to reduce the time spent checking incoming inspection reports without increasing incorrect assignments” is testable.
2. Data and usage rights
Required inputs can be found and accessed. Their formats, sources and quality are known. The company may process the data for the intended purpose and send it to the selected systems.
Include rare formats, incomplete documents and historic naming conventions in the sample. For personal or confidential data, clarify storage location, deletion periods and whether an external model provider may use the data.
3. Expert evaluation
Each important output has a definition of correctness. Subject-matter experts can evaluate results. A representative set of real cases is reserved for acceptance testing and is not used for ongoing system adjustment.
“Looks good” is not enough. Document extraction needs an expected value for each required field. A response draft needs criteria for facts, completeness and permitted statements.
4. Integration and permissions
The systems involved have stable interfaces or controlled import and export paths. Access rights can be limited to the use case. Test and production data are separate.
Read-only access is a good start. Write access to ERP, DMS or production systems increases risk. Add it only after the pilot works reliably in read-only mode and logs every change.
5. Consequences and human control
The team understands the consequences of a wrong result. Critical output reaches a person before triggering an effective action. Employees can reject or correct a recommendation and return the case to the normal process.
Human review only works when the reviewer has enough context, time and authority. A confirmation button without visible sources, or one shown hundreds of times per hour, is not a sound control.
6. Ownership and operation
A person in the business unit owns result quality. A technical owner covers interfaces, model changes and incidents. The team measures cost, quality and human intervention during operation.
Operational planning also needs a fallback and clear stop criteria. The system should stop or return to manual processing when quality falls below a threshold, a data source changes or a security incident occurs.
Scoring
This score is a working heuristic, not a standard or legal assessment.
Do not start a pilot on real cases if any of these stop criteria applies:
- The goal is not measurable.
- Data rights or usage rights remain unclear.
- Experts cannot reliably recognise a correct result.
- A relevant error has no safe control or recovery path.
- Nobody owns the quality of the result.
If no stop criterion applies:
- 10 to 12 points: The process is a good candidate for a limited pilot.
- 6 to 9 points: Start with a feasibility study and close the named gaps first.
- 0 to 5 points: Do not start an AI pilot yet. Clarify the process, data access or responsibilities.
Suitable industrial use cases
Good first use cases combine frequent, repeated cases with enough language or visual variation that fixed rules reach their limits. The result must remain testable.
Examples include:
- extracting data from inspection reports, delivery notes or technical specifications,
- matching and normalising product data from several sources,
- classifying maintenance reports and marking missing information,
- searching technical documentation and preparing answers with sources,
- triaging complaints and preparing the next processing step.
Autonomous safety decisions, direct changes to live production parameters and processes without representative example data are poor starting points. A rare task with little manual effort may not justify a custom AI solution either.
If the solution path varies and several systems are involved, an agent may fit. What is Agentic AI? explains the difference between an agent and a fixed AI workflow.
A complaint-handling pilot
Assume technical complaints arrive by email with PDFs and photographs. Today, an employee finds the product number, checks the documents, assigns the case and writes an initial question.
A limited pilot could:
- extract product number, batch and fault description,
- mark missing required information,
- suggest a product group and responsible team,
- prepare a response draft with open questions.
The pilot does not write to the primary system or send messages. It first runs on completed historic cases. It then runs in shadow mode alongside the existing process. Employees can see the suggestions, but the established process remains authoritative.
Predefined metrics decide the next step. Measure extraction accuracy per field, assignment errors per product group, factual errors in drafts, total processing time including correction and cost per completed case.
Only an end-to-end measurement shows value. A fast AI response saves nothing if employees spend longer checking it or correcting downstream errors.
Moving from test to operation
Move in small, testable stages:
- Historic cases: Measure quality against completed, representative cases.
- Shadow mode: Process new cases in parallel without triggering actions.
- Assisted operation: Employees accept or correct suggestions and every change remains traceable.
- Limited automation: Automate only actions shown to be safe. Uncertain cases still go to people.
The voluntary NIST AI Risk Management Framework recommends testing before deployment and continued measurement under realistic conditions. A fixed test set, version records and production metrics belong in pilot planning from the start.
Law, security and responsibility
Check the legal basis before sending data to a model. The EU AI Act requires providers and deployers to support AI literacy among staff. High-risk systems face further requirements around risk management, data quality, logging, human oversight and cybersecurity. Whether a specific system falls into this category depends on its intended use and needs legal assessment.
The GDPR also applies to personal data. A data protection impact assessment is required under Article 35 GDPR when processing is likely to create a high risk to people’s rights and freedoms.
These notes are not legal advice. They identify questions that should be answered before technical implementation.
If your process scores well, the next step is a short feasibility assessment with real sample data. Schmidt Embedded Systems provides AI consulting and data engineering. For variable solution paths, see our service for AI agent development.