AI-Assisted Writing Governance
AI Vendor Content Data Check
Evaluate what an AI writing vendor receives, retains, shares, uses for training, secures, exports, and deletes before approving content workflows.
Free editable Markdown · Procurement teams, privacy teams, and content leaders ·
Accessible HTML preview
Blank template
The downloaded file contains the same fields in editable Markdown.
Vendor and scope
- Vendor, service, feature, and plan
- [Enter]
- Contracting entity and region
- [Enter]
- Account or tenant type
- [Enter]
- Proposed use cases
- [List]
- Proposed data classes
- [List]
- Integrations and connected sources
- [List]
- Assessment owners and date
- [Enter]
- Evidence cutoff date
- [YYYY-MM-DD]
Data flow and purpose
- Prompt and file inputs
- [What enters?]
- Account and usage metadata
- [What is collected?]
- Generated output storage
- [Where/how long?]
- Human access by vendor
- [Purpose/control]
- Subprocessors
- [Reference/version]
- Storage and processing locations
- [Enter or Unknown]
- Training or model improvement
- [Default, opt-out, evidence]
- Safety, abuse, or service monitoring
- [Purpose/retention]
Control and lifecycle checks
- Retention periods by data type
- [Enter]
- Deletion behavior and backup expiry
- [Enter]
- Export and portability
- [Enter]
- Identity, roles, and administrator controls
- [Enter]
- Encryption evidence
- [In transit/at rest/other]
- Audit and activity logs
- [Availability/retention]
- Incident notice and response
- [Contract/evidence]
- Independent assurance
- [Scope/date, without overgeneralizing]
- Customer configuration verified
- [Owner/date/evidence]
Decision
- Unresolved questions
- [List]
- Permitted data classes
- [Exact scope]
- Prohibited data classes
- [Exact scope]
- Approved use cases
- [List]
- Required controls
- [Configuration, redaction, review, logging]
- Specialist decisions
- [Privacy/security/legal/procurement]
- Exit and deletion plan
- [Describe]
- Decision, owner, and expiry
- [Approve / Conditional / Reject]
- Reassessment triggers
- [Terms, subprocessors, incident, feature, region]
How to use this template
- Define the exact service, plan, configuration, integration, region, and proposed content workflows.
- Map all inputs, outputs, logs, people, systems, subprocessors, retention, and deletion paths.
- Collect dated evidence from contracts, official documents, settings, tests, and direct answers.
- Obtain privacy, security, legal, procurement, and operational decisions for the stated scope.
- Document approved data and use cases, configure controls, monitor changes, and plan exit.
Map the real content data flow
Begin with the proposed writing workflows and sample only synthetic data. Identify every input: prompts, pasted drafts, uploaded files, URLs, feedback, account details, telemetry, and support conversations. Then map outputs, logs, exports, integrations, subprocessors, storage regions, and administrative access. Distinguish public consumer services, managed workspaces, APIs, and optional features because terms and controls may differ. Record only facts for the exact plan and configuration under consideration. Marketing statements such as “enterprise grade” do not answer whether submitted text is retained, used to improve models, or exposed to connected services.
Resolve retention, training, sharing, and deletion precisely
Ask what is stored, for how long, for which purpose, under which default, and whether an administrator can change it. Separate model training from abuse monitoring, service improvement, human review, caching, backup, and legal retention. Identify subprocessors and cross-border transfers through the qualified review process. Test whether deleting a chat, account, file, or workspace removes the same records and how backup expiry works. Record export options and how the organization retrieves audit records. When the vendor answer is conditional or undocumented, write “unknown” and restrict the use case rather than filling the gap with an assumption.
Turn vendor findings into enforceable use boundaries
Evaluate identity and access management, encryption claims, incident notification, isolation, audit logs, certifications, vulnerability handling, contract commitments, and deletion support with security and procurement owners. Then connect the result to permitted data classes and use cases. A tool may be acceptable for public-content brainstorming but not for customer records or embargoed research. Require configuration evidence, an owner, review date, incident route, exit plan, and trigger for reassessment. If a material control depends on a setting, verify it in the actual tenant and monitor configuration drift instead of relying solely on a questionnaire response.
See the fields in context
Fictional example: public-copy brainstorming service
TextLantern and every plan, setting, and term below are invented and must not guide a real procurement decision.
- Scope: A managed fictional workspace for outline ideas using already published web copy.
- Unknown: The imaginary documentation does not state how long abuse-monitoring logs retain submitted text.
- Decision: Conditional pilot with public inputs only; customer, employee, confidential, and embargoed text are prohibited.
- Control: Administrators verify the fictional “no training” setting monthly and keep a tenant configuration record.
- Trigger: Pause on any data-term, subprocessor, integration, or incident-notice change.
Frequently asked questions
Is a vendor's privacy policy enough for approval?
Usually not. Review the applicable contract, service terms, plan, settings, subprocessors, security evidence, and direct answers for the exact workflow.
Does “not used for training” mean no content is retained?
No. Data may still be stored for delivery, safety, support, logs, backups, or legal obligations. Ask about each purpose and period.
Should vendor review happen once?
No. Reassess on contract, feature, configuration, subprocessor, data, incident, region, or use-case changes and at a scheduled expiry.
What if the vendor will not answer a material question?
Record it as unknown, narrow or prohibit the affected use, seek alternatives, or reject the vendor according to the risk and policy.