Not everything needs AI: the 3-question framework I use before automating

These days everyone shows up asking for "something with AI". But one of the projects I am most proud of does not have a single line of AI in it.

The case

An engineering team needed to create Tube & Pipe styles in Inventor from huge Content Center libraries. The manual process: open, configure, resolve component by component. Days of mechanical, error-prone work nobody wanted to do.

The solution was an add-in that reads an Excel file and creates the styles in bulk, resolving every component against the real Content Center families. Deterministic, auditable, repeatable. It runs the same today as it will a year from now.

An LLM there? It would have added cost, latency and error probability to a problem that was 100% rules. The input was structured (an Excel file), the output was defined (valid styles) and there was no ambiguity to interpret.

The 3-question framework

1. Is it a problem of clear RULES? If you can write the procedure on paper and it is always the same, it is classic automation. Period. Deterministic code: cheaper, faster, more reliable.

2. Is it about LANGUAGE, ambiguity or judgment? If the input is a human request, context changes and something must be interpreted, that is where an LLM belongs. Always with hard validations around it, because the model gets things wrong.

3. Is it a MESSY process? If the real problem is that everyone does it differently and nobody knows which version is right, neither AI nor code: fix the process first. Automating chaos just produces faster chaos.

I sell solutions, not AI

Sometimes the solution is a conversational agent inside Vault, with 9 defense layers. Sometimes it is a well-parsed Excel file. Whoever proposes AI for everything is not solving your problem: they are selling you theirs.