The phrase has been applied to almost every product in this industry, including ones that added a chat box. Here is a test that distinguishes them.
It has been applied to products built around machine learning and to products that added a summarisation feature last quarter. When a phrase covers both, it has stopped carrying information.
I use it about my own work, so this is a standard I am holding myself to as much as anyone.
Whether removing the capability would break the product, or merely remove a feature.
If the system was designed around what these methods make possible, taking them out leaves nothing. If it was designed first and the capability was added, taking it out leaves the original product, which is still fine.
Genuinely native systems change what the user does, not just how fast they do it. If the sequence of steps is identical and one of them is quicker, that is a good feature and not a different kind of product.
If you can remove it and the product still works, it is a feature. That is not an insult. It is a description.
Products built around a capability improve as the underlying methods improve. Products with a feature bolted on improve when someone rebuilds the bolt.
Over several years those diverge considerably.
What decisions the system makes that a rules-based system could not. What data it learns from and whether that is your data. What happens when it is wrong, and whether you can see why it produced a given output.
The last one is the most useful question, and the one vendors are least prepared for.
Descriptive only: riskDNA was built around analytical methods rather than having them added. Whether that produces a better result for any particular firm is a question for that firm, not a claim I am going to make on a website.