Grounded AI uses relevant business records and evidence to support an answer. Permission-aware AI applies the asking user’s authorised company context and access rights when retrieving information or preparing supported actions. Useful assistance needs both, with uncertainty made clear when the evidence is incomplete.
Both phrases have been worn smooth by marketing. They do describe something specific, though, and the distinction is the difference between an assistant you can act on and one you have to double-check — which is no assistant at all.
What grounded means
A language model asked "what did we pay for the aluminium extrusion on the Halbrook job?" can always produce an answer. Left ungrounded, that answer is a statistically plausible sentence in the shape of a cost. It may be a real number pulled from context, or it may be fabricated with total fluency. Nothing about the response distinguishes the two.
Grounding changes the sequence. Instead of answering from what the model learned in training, the system:
Three properties follow, and all three are testable.
- Traceability. Every figure points to a specific record — this purchase order, this receipt, this work order. You can click through and verify.
- Refusal. If the records do not contain the answer, the system says so. This is the single best indicator of real grounding: an ungrounded system almost never says "I don't know," because it has no way to tell that it doesn't.
- Currency. The answer reflects the state of the data now, not at training time or last night's export.
Ask a question whose answer is genuinely not in the system — a cost for a job that was never entered, a supplier you have never used. A grounded system tells you it has no record and, ideally, what would need to exist for the question to be answerable. An ungrounded system produces a confident, well-formatted, entirely invented answer. This takes thirty seconds and tells you more than an hour of feature walkthrough.
What permission-aware means
Most software enforces permissions at the interface: a user without rights to a page cannot open the page. That model quietly fails the moment you put a conversational layer over the data, because the AI is not navigating pages. It is querying records.
If permissions live only in the interface, a shop-floor user who cannot open the margin report can still ask "what margin are we making on the Halbrook job?" and get an answer — because the AI's retrieval never passed through the screen that was protecting it. The control was cosmetic.
Permission-aware means access rules are enforced at the data layer, on every retrieval, in the context of the specific person asking. The same question from two different people can and should return different answers, or a refusal for one of them. Practically, this requires:
- Retrieval filtered by identity, not filtered after the fact. Records the user cannot see must never enter the model's context in the first place — filtering the output is not a control, because the data has already been read.
- Field-level as well as record-level rules. A user might legitimately see a purchase order's delivery date but not its unit price.
- Tenant isolation underneath all of it. In a multi-company platform, no query path should be able to cross a company boundary regardless of how it is phrased.
- Rules that apply to aggregates. Being unable to see individual salaries is meaningless if you can ask for the departmental average and the headcount.
Why both words are needed
Each property fails in a specific way without the other.
| Not permission-aware | Permission-aware | |
|---|---|---|
| Not grounded | Invents answers, and would leak data if it had any. Unusable. | Invents answers within a boundary. Safe and useless. |
| Grounded | Accurate answers drawn from records the asker should not see. Dangerous precisely because it is correct. | Accurate answers, correctly bounded. The only usable quadrant. |
The bottom-left cell deserves emphasis. A grounded system without permission awareness is more dangerous than an ungrounded one, because everything it says is true. Nobody questions it, and the disclosure is both accurate and complete.
The action boundary
Reading information, preparing a proposal and committing a business action need different controls. Evaluate the actual supported actions rather than assuming an AI can perform everything available in the application.
| Activity | Example | Control to check |
|---|---|---|
| Read | Explain an outstanding order | Authorised record access and supporting evidence |
| Analyse | Compare project-cost categories | Defined calculations, scope and cut-off |
| Prepare | Propose a supported change | Clear proposed values and a reviewable result |
| Commit | Apply an approved action | Required confirmation, user permissions and business rules |
| Unsupported or prohibited | An action outside the available workflow | A clear limit rather than an improvised workaround |
AI assistance should not expand the asking user's authority. Confirm how approval requirements, financial controls and reversal rules apply to each supported action.
Auditing what the AI did
Whatever the AI touches has to be reconstructible afterwards. That means recording, for every interaction: who asked, what they asked, which records were retrieved, what was proposed, who confirmed it, and what changed as a result.
Two consequences are worth stating. First, an AI-initiated action should be as auditable as a human one — ideally more so, since the reasoning and sources can be captured alongside the change. Second, the audit history has to be immutable. An audit trail that can be edited by the same system that writes it is documentation, not control.
Questions to ask any vendor
- Show me the AI answering a question it has no data for. What does it say?
- Can I click from any figure in an answer through to the underlying record?
- Are permissions enforced on retrieval, or applied to the output afterwards?
- Ask the same question as two users with different rights — show me both answers.
- What can the AI do without a human confirming? Show me that list.
- Is my operational data used to train models, for you or for anyone else?
- Where does the data go when a question is asked, and who processes it?
- Show me the audit record of an AI-proposed action after the fact.
The training-data question deserves a written answer, not a verbal reassurance. It should also cover subprocessors, since the model provider is usually a different company from the software vendor.
How Datum handles it
Dot brings records, documents, analysis and supported actions into the conversation. Supporting records help your team examine the basis of a finding. If evidence is missing or insufficient, the answer should make that limitation clear.
Datum applies authorised company context, access controls and business rules to the work. Calculations and business actions belong to the application's controlled services; the model's explanation does not replace those controls.
Dot can prepare supported work for review. Applicable confirmation and approval requirements govern execution, and resulting business actions retain the history recorded by their owning workflows. The Security page explains company isolation, permissions and traceable actions.
What to check in your setup
- Ask a real question and inspect the records supporting the answer.
- Check the available actions and review requirements with users who have different permissions.
- Agree your edition, Dot usage terms and any custom work through the scoped proposal.
Related questions
How is grounded AI different from a general chatbot?
A general chatbot answers from patterns learned in training. A grounded system retrieves the relevant records first — the purchase order, the receipt, the job — and answers only from what it retrieved, showing the sources. If the records do not contain the answer, a grounded system should say so rather than guess.
Does permission-aware mean the AI hides pages, or hides data?
Data. Page-level permissions only control what a user can open. Permission-aware AI applies access rules to every record the AI retrieves, so a question phrased to bypass the interface still cannot surface figures the user is not entitled to see.
Can operational AI take actions on its own?
It depends on how the system is configured, and the safe default is no. A well-governed system lets the AI prepare an action — a draft purchase order, a proposed reallocation — and requires a permitted human to confirm before it is committed. Every action, proposed or confirmed, should land in the audit history.
What should the AI do when it does not know?
Say so, and say why. The valuable behaviour is a clear statement that the records do not contain the answer, along with what would need to be recorded for the question to become answerable. Confident invention is far more expensive than an admitted gap.