When your organisation adds a new tool to its stack, your security team reviews it. For an AI tool, that review has specific angles. Security reviewers do not accept hand-waving about models or privacy; they need answers about data, access, and auditability. Preparing those answers now saves friction later.
Data flow and retention
The first question is always: where does the data go? For an AI tool, trace the complete path. Does the tool send any data to external APIs? If so, which ones, and what exactly is sent — just the query, or also metadata like user identity, timestamps, or document metadata? Can administrators control or disable external integrations, or are they built-in?
How long is data kept? Chat history, query logs, uploaded documents, audit records — each has different retention requirements. Reviewers want to see that the tool keeps data only as long as necessary and that administrators can delete or export it on demand. If the system automatically purges old conversations after 90 days, say so. If you can export your data to your own storage, document that.
Where is data stored geographically? If you operate in multiple regions or have data residency requirements, you need to know where databases and backups live. Cloud-based tools should publish which regions they use; self-hosted tools should let administrators choose their own infrastructure.
Sub-processors and external integrations
Most AI tools integrate with other services — model APIs, logging platforms, payment processors, or security vendors. These sub-processors touch your data indirectly, and reviewers need a complete list. Which external services does the tool use by default? Which are optional and can be disabled? Are there any cloud services hard-wired into the system that administrators cannot control?
For each sub-processor, know: what data flows to it, and whether the tool's vendor has a data processing agreement in place with that sub-processor. If you are using hosted LLM models, the vendor should have contracts in place before you send queries. If those contracts or sub-processor relationships change, there should be a notification mechanism or a way to opt out.
Access control and user management
Who can access the tool? Is access tied to your organisation's authentication system (SAML, OAuth), or does the tool manage its own logins? Can administrators control which users have access, and can they revoke access immediately? Can you enforce multi-factor authentication company-wide?
Can access be restricted by role, team, or department? If your organisation needs to ensure that only certain people can use it — perhaps data scientists only, or only members of the security team — the tool should support that granularity. Overly permissive access is a finding in security reviews.
Can you see who used the tool and when? If the system can generate reports of usage by user and date, that is valuable for audits and incident response. If access is a black box, that is a concern.
Audit logging and visibility
Security reviewers ask: what activity does the tool log, and can you access those logs? Ideally, the tool records: who accessed it, when, what they queried, what documents they uploaded or used, what external APIs were called, and when. Logs should be stored separately from the main application so that an attacker who compromises the app cannot erase the trail.
Can logs be exported to your own logging system (Splunk, ELK, CloudWatch) or is the vendor the only source of truth? Integration with your existing audit infrastructure is a plus but not strictly required. What matters is that logs exist, are tamper-resistant, and can be produced if regulators or your security team ask.
API key and credential handling
If the tool accepts API keys from external services — for hosted LLM models, payment processors, or other integrations — reviewers want to know: how are these credentials stored? Are they encrypted at rest? Can administrators see the full key, or only a masked portion? Can keys be rotated without downtime?
Self-hosted tools should store keys on the server-side only, never in configuration files that ship with the software or in backups that might be moved between machines unencrypted. If your team adds a key, and then later an administrator upgrades the software or migrates to a new server, the key should not leak in logs or migration files.
Preparing for the conversation
When a reviewer asks about an AI tool, have answers ready: a diagram or summary of data flow; a list of sub-processors and what data each touches; documentation of access controls and how to audit usage; information about data retention and how to export or delete data; how the tool stores credentials. You do not need to solve every possible edge case, but you need to show that you have thought about these questions and have ways to verify the answers later.
Self-hosted tools like Nodus Veritatis give you direct visibility into infrastructure, data flow, and access logs because they run on your own servers. You control what data is uploaded, which external models are enabled, and where logs are stored. That transparency is an asset in a security review. But any AI tool — hosted or self-hosted — needs to be able to answer the same core questions: what data goes where, who can access it, and how can you verify that the answers are true.
Security review is not a test to pass with the right phrasing. It is an alignment process: your security team needs confidence that the tool fits your risk tolerance and compliance obligations. Clear answers about data, access, and auditability earn that confidence.