There is no shortage of advice about AI strategy. Most of it is either too abstract to act on or too specific to survive contact with your particular company. After a number of deployments, three rules have held up every time, and breaking any one of them has predicted failure more reliably than any technical factor.
Rule 1: If you cannot check the answer, do not automate the question
This is the rule that decides whether a project is possible at all, and it is the one most often broken at the proposal stage.
Some questions have a verifiable answer. Does the purchase order revision match the drawing revision? Does the bill of materials list the same number of washers the drawing shows? Is a tolerance missing from this dimension? A person can look and say yes or no, and two people will agree.
Other questions do not work that way. Is this the right design? Should we take this order? Is this candidate good? These are judgement calls where two competent people legitimately disagree, and a system that produces a confident answer to them is not helping you — it is laundering a guess into something that looks authoritative.
| Safe to automate | Not safe to automate |
|---|---|
| Does the order match the drawing? | Should we accept this order? |
| Is a tolerance missing? | Is this tolerance the right one? |
| Which documents reference this dimension? | Which of these documents matters most? |
| Has this candidate worked with SAP? | Is this candidate a good hire? |
The right-hand column is not off-limits forever. It is off-limits as a first project, and it is permanently off-limits as something that acts without a person deciding.
Rule 2: The system must show its work
An output with no provenance is a rumour. If the system says a dimension is missing, it has to show you where on which sheet. If it says the order and the bill of materials disagree, it has to show you both lines. If it answers a question about a specification, it has to name the document and the clause.
This is not a nice-to-have for regulated manufacturers — it is the difference between something an auditor accepts and something that creates a finding. But it matters just as much for adoption. People do not stop using a system because it is occasionally wrong. They stop using it because they cannot tell when it is wrong, so checking its output costs as much as doing the work themselves.
Rule 3: Fit your process, do not replace it
The most common way a technically sound deployment dies is that it asks people to work somewhere else. A new portal, a new inbox, a new set of templates in the vendor's format rather than yours. Each of those is a small tax, and collectively they are enough that within a quarter the tool is something people are supposed to use rather than something they do use.
Your customer approved your control plan in your format. A cleaner document in a vendor's format is not an upgrade, it is a second document to reconcile. Your team lives in Outlook and Excel; a system that produces work there will be used, and a system that requires a login somewhere else will be used for three weeks.
- 1Arrive where the work already arrivesIf drawings come by email, the system should read email. Requiring somebody to upload files to a portal adds a manual step to a project whose entire purpose was removing manual steps.
- 2Produce your documents, not new onesEditing your existing Word and Excel templates with tracked changes beats generating a beautiful new artefact that nobody has approved and nobody is contractually allowed to send.
- 3Keep the approval where it isIf a quality manager signs things off today, they should sign these off too, in the same place. Moving the approval is a change-management project bolted onto a technology project, and it will sink both.
Why these three and not thirty
Because they are the ones that fail loudly. Break the first and you build something nobody can validate. Break the second and you build something nobody trusts. Break the third and you build something nobody uses. Almost every other piece of AI advice is downstream of these, and a project that gets all three right tends to survive its own mistakes elsewhere.