What it means
The word has been stretched until almost every vendor uses it, so a narrower test is more useful: where does the AI get its data, and under whose rules does it act? In an AI-native system the model reads the same records, through the same permissions, as every other part of the product. In an AI-added system it reads whatever one product exposes, often through a sync or an export.
A quick tell is where the AI appears in the product. If it lives in one module’s sidebar and nowhere else, it was probably added to that module.
Why it matters when you choose software
The questions worth asking an assistant rarely stay inside one department. “Which clients with open support tickets are also late paying?” crosses sales, support and finance. If those live in separate products, an assistant attached to one of them sees a third of the answer and states it fluently anyway.
The cost shows up after the demo, not during it. Demos are staged inside one product, where added-on AI works well. Daily work crosses boundaries, and that is where it narrows.
Questions to ask a vendor
- Can it answer one question that spans two areas of the business, live, on our data?
- Does the AI read the records directly, or a copy synced on a schedule?
- Does it run under the permissions of the person asking, or under a service account?
- When it changes something, where is that recorded, and can the change be undone?
- Is the AI sold as a separate product, or is it part of the platform?
How Cyril approaches it
Cyril is built on one schema, one permission model and one audit log, with the AI layer underneath every module rather than attached to one. Every entity has an ai_context serializer, a view of the record built for the model. Ask Cyril works inside the permissions of the person who asked, shows its plan and waits for approval before it acts. Cyril is pre-launch, so this describes how the platform is built, not results from customers.