An enterprise generative AI security review checklist
Review enterprise AI data flows, document permissions, external connections, retention, deletion, and incident ownership with practical questions and test scenarios.
An enterprise generative AI security review covers more than the model name and installation location. It needs to establish what data is connected, who can access it, where prompts and responses remain, and who responds when something goes wrong.
Start with one workflow. Map its data flow, then attach questions about access, retention, deletion, and operations to each stage. This creates a manageable review before you assess every possible feature.
Map source files, intermediate data, and logs
Trace the path from repository to answer screen. Distinguish original files, extracted text, document chunks, embeddings, search indexes, model inputs, conversation history, and operational logs.
For each item, record execution and storage location, access accounts, retention, and deletion procedures. A promise not to use data for training is different from a promise not to store it. External transmission is another separate consideration.
Wissly does not use customer documents, prompts, or responses for model training, retraining, fine-tuning, or its own model improvement. Depending on the feature and selected model, SaaS AI processing uses Amazon Bedrock or Google Cloud Vertex AI. On-premises processing uses local AI within the internal network. Discuss your required processing conditions when reviewing an Enterprise configuration.
Pair each question with a way to check it
| Area | Question | Check |
|---|---|---|
| Connected data | Which repositories and folders are read? | Review connected and excluded paths together |
| Ingestion accounts | What can the collection account access? | Test allowed and blocked folders |
| User permissions | Do users have distinct search scopes? | Run the same query under different accounts |
| Model requests | What reaches which model? | Review request paths and network settings |
| Retention and deletion | How are files, indexes, history, and logs removed? | Identify locations and removal procedures |
| Support access | How is provider access approved? | Check approval, revocation, and ownership |
| Updates | How are versions and models admitted? | Review update and recovery procedures |
Record a configuration, owner, or contractual scope rather than simply writing “supported.” Where an item is not applicable, include the reason so future reviews can understand the decision.
Check permissions before generation
If an inaccessible document reaches the model, hiding its link in the final response may still expose its contents. Include titles, search summaries, quoted passages, and conversation history in the test.
Security filtering for document search is one implementation pattern worth understanding. A filter alone does not provide the full authentication and authorization system. Test the complete behavior with real account roles and representative documents.
For example, create a general project folder and a restricted quotation folder. Ask about quotations using an account that cannot access the restricted folder. Inspect the answer, document title, quoted text, and original-file access. Repeat after changing that account's permissions.
Include instructions embedded in documents
Retrieved files can contain instructions unrelated to their business content. OWASP's prompt injection guidance explains why using RAG does not remove this risk.
Place an unrelated instruction in a test document and observe the response. If the system can run tools or send information elsewhere, also examine allowed actions and approval conditions. Use test data so the exercise can be controlled without involving sensitive production material.
Review changes as well as the initial installation
New documents, employee transfers, account removal, and model replacement can change the conditions that passed the initial review. Define who approves each change and what must be retested.
For identity and audit features such as SSO, SCIM, and audit logs, specify your required method and contractual scope. These are also topics to confirm when scoping Wissly Enterprise. Provide the account model and log fields you need instead of assuming every deployment includes every capability.
Use the document update and deletion guide to shape operational checks, and include permission scenarios in your RAG PoC evaluation. This connects security review and workflow evaluation through the same documents and accounts.