AIforBC practical guide
AI vendor privacy and security checklist
Before information enters an AI system, understand what is collected, why it is needed, where it goes, how long it remains, who can access it, and what happens when the system is wrong.
Short answer
An AI vendor review should follow the data from collection to deletion.
Ask the vendor to document the purpose, data categories, legal and contractual roles, model-training use, storage location, subprocessors, retention, access controls, incident response, human oversight, and exit process. Match the depth of review to the sensitivity of the information and the consequence of a wrong output.
Start with the data inventory
List the information the proposed workflow might use: public material, internal documents, customer records, employee information, financial data, health information, contracts, intellectual property, credentials, or system logs. “The tool is secure” is not meaningful until everyone agrees on what data is in scope.
BC’s Personal Information Protection Act regulates many private-sector organizations that collect, use, or disclose personal information. The correct legal analysis depends on the organization and use case, so obtain qualified advice where necessary.
The 18 questions to send an AI vendor
- Purpose: What exact service function requires each category of information?
- Collection: Does the product collect prompts, uploads, outputs, metadata, telemetry, or user feedback?
- Training: Are customer inputs or outputs used to train, tune, or evaluate any model?
- Control: Can model-training use be disabled contractually and technically?
- Location: In which countries and regions are data processed and stored?
- Subprocessors: Which other companies receive or process the information?
- Retention: How long are prompts, files, logs, and backups kept?
- Deletion: How is deletion requested, verified, and propagated to backups or subprocessors?
- Access: Which vendor personnel can access customer information, and under what controls?
- Identity: Does the product support single sign-on, multi-factor authentication, and role-based access?
- Encryption: Is data encrypted in transit and at rest, and how are keys managed?
- Isolation: How is one customer’s information separated from another customer’s data?
- Incidents: What is the notification process and timing after a suspected breach or harmful AI event?
- Testing: How does the vendor test security, accuracy, bias, misuse, and failure modes?
- Oversight: Can important outputs require human approval before action?
- Records: Are prompts, sources, versions, corrections, and approvals logged when needed?
- Portability: Can the organization export its information and operating records?
- Exit: What is deleted or retained after the contract ends?
Separate security evidence from marketing language
Ask for current, relevant evidence and define what it proves. A certification or audit may cover only certain systems, locations, or dates. A penetration test does not prove output accuracy. A privacy policy does not prove that the proposed configuration meets your use case.
| Evidence | What to confirm |
|---|---|
| Independent audit or certification | Scope, period, exclusions, and whether the service you will use is included. |
| Security architecture | Data flow, identity, access, encryption, isolation, logging, and incident controls. |
| Privacy documentation | Purpose, roles, subprocessors, locations, retention, deletion, and rights handling. |
| Model documentation | Capabilities, limitations, evaluation methods, known failure modes, and update practices. |
| Contract terms | Training use, confidentiality, breach duties, deletion, liability, support, and exit rights. |
Use stronger controls for higher-consequence work
For sensitive or consequential workflows, consider a restricted pilot, approved accounts, minimal data, synthetic or redacted test records, documented human approval, logging, quality sampling, and a named incident owner. Do not let an AI system make an irreversible decision merely because the workflow can be automated.
If a vendor will not clearly explain data use, subprocessors, retention, deletion, or the limitations of the system, the business does not yet have enough information to approve the deployment.
What to document internally
Keep a short decision record: the business purpose, approved users, permitted data, prohibited data, vendor and product version, risk owner, human-review rule, baseline, evaluation period, incidents, and the decision to expand or stop. This creates accountability without requiring a large governance program for every low-risk experiment.
Source trail
Primary sources used in this guide
- Resources for private organizationsOffice of the Information and Privacy Commissioner for British Columbia
Official BC resources on PIPA, privacy management, security self-assessment, breaches, and cloud computing.
- AI, privacy, and your businessOffice of the Privacy Commissioner of Canada
Federal privacy regulator guidance on consent, transparency, safeguards, explainability, and privacy by design.
- Voluntary Code of Conduct on Advanced Generative AI SystemsInnovation, Science and Economic Development Canada
Canadian voluntary measures covering accountability, safety, transparency, human oversight, monitoring, validity, and robustness.
- Generative AI Profile (NIST AI 600-1)U.S. National Institute of Standards and Technology
Cross-sector guidance for identifying and managing generative AI risks.
AIforBC uses official and primary sources where practical. This guide provides general operational education, not legal, privacy, cybersecurity, or financial advice.
Need help choosing?