In brief
- Secure AI is not a feature of the model. It is a set of controls around the model: data location, document permissions, limits on actions, logging, and vendor terms.
- Most real failures are ordinary: a shared folder an assistant can read, a client file pasted into the wrong tool, an assistant with more access than its task needs.
- Ask for evidence, not adjectives. A sample log, a data flow description and a SOC 2 report you can read tell you more than "enterprise grade".
Secure AI for business is AI your company can use on real work without losing control of its data, its permissions or its paper trail. The model is only one piece of that. Most of the security sits around it: where information is stored, which documents a person's question can reach, what the assistant may do without asking, and what gets written down afterward.
Why "the model is safe" is the wrong question
Vendors usually answer security questions with a statement about the model. It does not train on your data. It is a leading model. It is enterprise grade. The first of those is worth having. None of them tells you whether the system around the model behaves.
Picture a well-behaved model sitting behind a retrieval layer that ignores who is asking. A junior analyst types a harmless question and gets an answer built from a board memo she was never meant to see. Nothing was hacked and the model did what it was built to do. The failure lives in the permissions.
That is why AI risk guidance looks at the whole system. The NIST AI Risk Management Framework organizes the work into four functions: govern, map, measure and manage. Its Generative AI Profile, released in July 2024, applies that structure to the risks specific to generative AI. Both are voluntary. Their practical value is a shared vocabulary, which helps more than you would expect when a security team and a vendor are talking past each other.
Five places where secure AI succeeds or fails
Where the data is stored and where it is processed
These are two different questions, and vendors often answer only one of them. Storage is where your workspace, files and history live. Processing is where a model reads your request and writes an answer, and with an external model provider that can be somewhere else entirely.
Ask for both in writing: the storage region, every provider that may process a request, the region each one processes in, what each retains, and what happens when your preferred option is unavailable. People skip the last one. A system that quietly falls back to a model in another country when yours is down gives you a different answer to "where does my data go?" depending on the hour.
Who can see which document
Imagine a 60-person firm that connects a shared drive to an AI assistant. One folder has loose permissions and holds a salary spreadsheet. Before the assistant, nobody looked there. After it, anyone can ask what the controller earns.
AI does not create permission problems. It makes the existing ones easy to find. For any assistant that reads company files, the question is whether it checks the asker's permissions at the moment of answering, using the rules of the source system, or whether it flattens everything into one searchable pile.
What the AI may do on its own
Answering a question is one thing. Calling a tool is another: sending an email, updating a record, deleting a file. A model proposing an action does not mean the action is authorized, and a design that treats the two as the same is how small mistakes become incidents.
The OWASP Top 10 for LLM Applications names this problem excessive agency, and it lists prompt injection, where text inside a document or web page steers the model, among the leading risks. Models cannot reliably tell instructions from data, so the practical defense is to limit the damage. Give each assistant only the tools its task needs, check permissions on the server for every tool call, and require a person to approve anything that changes data or acts in an outside system.
What gets recorded
When a client asks what happened to their file, or an auditor asks who used which model on which data, you need a record. A useful log says who asked, which model answered, where it ran, which policy applied and what the action produced. Those logs hold sensitive material themselves, so who can read them matters as much as having them.
Who else is involved
Every AI tool sits on a chain: the vendor, its cloud host, the model providers, sometimes subprocessors beyond them. The AICPA's SOC 2 reports are the usual way to see whether an independent auditor examined a service organization's controls. They are organized around the trust services criteria: security in every report, plus availability, processing integrity, confidentiality and privacy when the company includes them. A Type I report describes the controls as designed on one date. A Type II report tests whether they operated over a period.
A SOC 2 report covers the provider's controls. It does not certify that every answer is right, or that a model provider further down the chain follows the same rules. Ask for the report, read the scope and the period, and look at the exceptions.
A short buying checklist
| Question | A weak answer | An answer worth trusting |
|---|---|---|
| Where is data stored and processed? | "Secure cloud" | Named regions for storage and for each model provider, and what happens when one is unavailable |
| Who can see which document? | "Role-based access" | Permissions checked on every request against the source system's rules |
| What can the AI do alone? | "Agents automate your work" | Tool limits per assistant, server-side checks, human approval for changes |
| What is logged? | "A full audit trail" | A sample log showing user, model, region, policy and result |
| Who else touches the data? | "Trusted partners" | A subprocessor list, data processing terms and a SOC 2 report you can read |
What this looks like at Davy
Davy's security page gives its own answers to these questions, and they deserve the same testing as anyone else's. Persistent workspace data is stored encrypted on U.S. infrastructure. The company chooses which models and processing regions are allowed, and if a request must be processed in the U.S. and no U.S. model is available, the request stops instead of going abroad. Requests are not used to train models. Access and action permissions are checked on the server for every tool call, human approval can be required for actions that change data, and the model used, the processing region, the policies applied and the result are logged. Davy states that data is hosted on SOC 2 compliant infrastructure. As with any vendor, have your own security team review the supporting documents.
Start with one workflow and one page of rules
You do not need a program to begin. Pick one team and one set of documents, write a single page that says which kinds of data may go to AI and which may not, and decide who approves exceptions. Run it for a month and read the log. The Enterprise page describes the adoption program Davy runs for larger organizations, but the order works without anyone's help: rules first, then one workflow, then a review of what actually happened, then more.
This post is general information, not legal or compliance advice.
