A useful dealership assistant needs context. It does not need unrestricted database access.

Those two ideas are often confused. The shortest demo is to connect a model to a warehouse and let it write queries. The safer production design is to give it a small set of tools that already know the store's definitions, permissions and limits.

A tool is a contract

Consider the question, "How many used units did we sell last month?" Raw table access asks the model to discover the schema, choose the date, identify retail versus wholesale, handle unwinds and decide which stores the user may see.

A governed tool can be named get_delivered_units. It accepts store scope, date range and sale type. The query inside it is owned, tested and versioned. It always excludes wholesale unless explicitly requested. It logs who called it and returns the definition with the answer.

The model still provides a natural interface. The business logic stays outside the model.

Least privilege and least agency

The FTC Safeguards Rule requires access controls, encryption, multifactor authentication, monitoring and service-provider oversight for covered customer information. OWASP identifies excessive agency as a major risk in systems where a model can take actions through tools.

The practical response is to separate capabilities:

A user who may see one rooftop should not gain group access because the assistant has a broad service account. A drafting agent should not inherit send authority. A recall workflow should not be able to query finance fields.

Put definitions in code, not prompts

Prompts are useful instructions. They are not hard controls. "Never count wholesale as retail" belongs in the query and test suite. "Never contact a customer more than twice in seven days" belongs in the send function. "Do not expose SSNs" belongs in the view and permissions.

NIST's AI Risk Management Framework emphasizes documented roles, oversight, testing and measurement. A tool layer makes those controls inspectable. It also makes the assistant easier to improve because the store can tell whether the failure came from language understanding, business logic, data or authorization.

The production checklist

  1. Inventory the questions and actions users actually need.
  2. Create the smallest tool for each job.
  3. Return source dates, definitions and row counts with answers.
  4. Enforce user and store scope outside the model.
  5. Require approval for customer contact, data export and material operational changes.
  6. Add duplicate guards, frequency caps and retry safety.
  7. Log every call, result, approver and final outcome.
  8. Test denied actions as seriously as successful ones.

AI becomes valuable when it can reach the store's real context. It becomes trustworthy when that reach is narrow, explainable and receipted. Give it tools, not the keys to every table.

The takeaway

Encode dealership definitions and permissions inside narrow tools, then let the model choose among those tools.

Sources and further reading

External sources support the public facts and frameworks above. Store-level outcomes remain qualitative unless they are already published and verifiable.