checklist

AI chatbot memory and personalization privacy checklist for small teams

A practical checklist for reviewing saved chatbot memory, personalized context, data minimization, user controls, deletion, access boundaries, and safe rollout.

Published: Sep 8, 2026 Last reviewed: Sep 8, 2026 Audience: Founders, product owners, engineering owners, platform owners, support leads, security owners, privacy owners, and reviewers operating AI chatbots with saved memory or personalized context Risk: High Evidence: NIST Privacy Framework, NIST AI RMF Core, NIST AI RMF Generative AI Profile, OWASP LLM02:2025 Sensitive Information Disclosure, CISA secure AI system development guidance, and Cybergiz chatbot operations checklists

Use this checklist when an AI chatbot stores conversation facts, preferences, profile attributes, summaries, embeddings, feedback, or other context for later personalization. It applies to consumer assistants, customer support bots, internal copilots, and agent routes that keep state across sessions.

The short answer: treat saved memory as a separate data-processing system, not as a harmless prompt feature. Inventory each memory field, document its purpose and source, minimize what is stored, give the right people understandable notice and controls, enforce identity and tenant boundaries at read and write time, and prove that deletion and opt-out remove the data from every relevant path. Keep memory disabled, session-only, or narrowly scoped when the team cannot prove those boundaries.

Start with the AI Tool Risk Checker to record the chatbot route, data, actions, and owner risk. Use the Small Team AI Security Checklist for identity, access, logging, incident, and vendor foundations. Pair this page with the AI chatbot retrieval access control and tenant isolation checklist, the AI chatbot deletion and export request workflow, the AI chatbot conversation log retention policy template, and the AI chatbot evaluation and regression testing checklist.

Bottom line

Saved memory can make a chatbot more useful, but it also creates a durable record that may be reused in a different conversation, tenant, role, or decision context. A successful login and a reassuring privacy setting do not by themselves prove that a memory is correctly scoped or deleted.

A defensible memory design can show:

What is stored, where it is stored, how it was created, and why it is needed.
Which subject, tenant, role, route, and purpose can write, read, correct, export, or delete each memory item.
That sensitive or high-impact inferences are not silently persisted as ordinary preferences.
That opt-out, correction, deletion, expiry, account closure, and tenant offboarding reach memory stores, indexes, caches, backups, exports, logs, and downstream tools as applicable.
That personalization cannot override authorization, safety policy, retention rules, or human approval requirements.
That negative tests prove a memory from one context does not appear in another context.

The NIST Privacy Framework is a voluntary tool for identifying and managing privacy risk through enterprise risk management. NIST guidance emphasizes identifying data processing, selecting target outcomes, verifying controls, and reassessing when the system or data lifecycle changes. OWASP LLM02:2025 treats personal, financial, confidential, credential, and legal information as sensitive disclosure risks in the model and application context. This checklist applies those principles to saved chatbot state; it is not a legal determination, compliance certification, or guarantee of a vendor feature.

This is operational guidance, not legal advice, a compliance certification, or a security assurance opinion.

When to use this checklist

Change or trigger	Use this checklist?	Minimum review
Enabling saved memory or personalization	Yes	Memory inventory, purpose, notice, controls, deletion test, owner, and release decision.
Changing what a chatbot remembers	Yes	Field classification, minimization review, user control, regression cases, and migration plan.
Adding a connector, profile source, or customer record	Yes	Source permission, tenant scope, write/read path, retention, and export review.
Changing model, prompt, ranking, or context assembly	Yes	Memory retrieval tests, sensitive-data tests, prompt-injection tests, and version record.
Adding support, analytics, cache, or backup access	Yes	Need-to-know review, redaction, retention, access logs, and deletion propagation.
User opt-out, correction, deletion, or account closure request	Yes	Request identity, scope, completion evidence, and residual-data verification.
Incident, complaint, unexpected personalization, or cross-context result	Yes	Containment, affected memory scope, root cause, regression case, and restart decision.
Session-only context with no persistence	Usually lighter	Confirm no hidden memory, cache, transcript, export, or provider-side state is used.

Treat an inferred preference, profile label, or embedding as data that needs a purpose and boundary even if it is not displayed to the user as a sentence.

Memory privacy review intake form

Complete this before enabling or materially changing memory.

Field	Record
Review ID and date	`memory-YYYY-MM-DD-NNN`
Product and route	Chatbot name, URL or interface, environment, and deployment target.
Use case	What personalization is supposed to improve and for whom.
Memory owner	Person accountable for the data lifecycle and rollback.
Data subjects	Users, customers, employees, contacts, tenants, or other affected people.
Memory sources	Conversation turns, profile fields, connectors, feedback, imports, or support records.
Memory stores	Application database, vector index, cache, transcript store, provider feature, export, and backup.
Allowed fields	Exact facts or preferences that may be stored.
Prohibited fields	Sensitive, unnecessary, speculative, or high-impact inferences that must not persist.
Read and write contexts	Subject, tenant, role, route, purpose, and approval needed for each operation.
Retention and expiry	Default lifetime, refresh rule, deletion trigger, and backup treatment.
User controls	Notice, view, correct, delete, disable, export, and appeal paths.
Support and vendor access	Roles, ticket process, audit trail, and time limits.
Evaluation pack	Current memory privacy and security test IDs and previous baseline.
Release decision	Approve, pilot, session-only, restrict, rollback, or pause.

Checklist:

The owner can describe the entire memory lifecycle without relying on a model response.
The environment uses synthetic or approved masked fixtures for testing.
Each stored field has a purpose, source, classification, and expiry or review rule.
The route distinguishes user-provided facts from model-generated inferences.
User controls are defined in plain language and have an operational owner.
The prior approved memory configuration and evaluation run are recorded.

Memory and personalization data map

Draw the path from a conversation or source record to each place where state can be copied, derived, displayed, or acted upon.

Stage	What to inventory	Boundary question
Capture	Message, form, feedback, connector record, or support note	Was the data intentionally provided for this purpose?
Extraction	Rule, classifier, model summary, or human label	Can an incorrect inference become a durable fact?
Storage	Row, document, vector, cache, transcript, or provider state	Is the store scoped to the correct subject and tenant?
Retrieval	Search, profile lookup, context assembly, or ranking	Is memory retrieved only for an authorized purpose?
Display	Answer, suggestion, profile screen, citation, or agent context	Could the display reveal a hidden or sensitive attribute?
Action	Ticket, CRM update, recommendation, message, or tool call	Can memory influence a high-impact action without review?
Copy	Export, log, analytics, backup, support ticket, or test fixture	Does the same retention and deletion rule follow the copy?
Removal	Delete, expiry, correction, opt-out, or account closure	How is completion verified in every relevant store?

Data-flow checklist:

The map includes caches, embeddings, indexes, logs, backups, and exports, not just the primary database.
Every derived value is labeled as fact, preference, prediction, summary, or uncertain inference.
The route records which memory items influenced an answer or action where practical.
A memory item cannot silently grant a role, permission, approval, or eligibility decision.
Each copy has an owner, access rule, retention rule, and deletion or exception path.

Data classification and minimization matrix

Use the narrowest category that supports the approved use case. Do not store a detail just because it may improve a future answer.

Memory type	Default	Example handling	Review trigger
User-selected preference	Consider	Store only if visible, editable, and useful to the user	Purpose or product change.
Short-lived task context	Session-only	Keep in the active workflow and expire after completion	Longer retention request.
Account or tenant setting	Consider with owner	Store in an authorized system of record, not only in model memory	Role, tenant, or plan change.
Support or workflow history	Restricted	Link to approved record with access and retention controls	New support or export path.
Sensitive personal or financial detail	Usually prohibit	Use a controlled system of record or explicit approved workflow	Any request to persist or retrieve.
Credential, secret, or authentication material	Prohibit	Never use chatbot memory as a secret store	Any observed occurrence.
Health, employment, legal, or high-impact attribute	Restricted/prohibit	Require domain owner, purpose, notice, and human review	Any model-generated inference.
Model-generated preference or profile inference	Do not silently persist	Show, label, confirm, and allow correction before storage	Confidence or purpose changes.
Cross-tenant aggregate or analytics feature	Restricted	Use approved aggregation and access controls	New population or purpose.

Minimization checklist:

The system can answer the use case without persisting the field, or the reason for persistence is documented.
Exact values are preferred over broad hidden profiles only when needed.
Sensitive fields are rejected before memory write, not merely hidden in the UI.
The retention period is no longer than the purpose requires.
The memory view exposes enough information for correction without revealing unrelated records.
The team has a fallback for users who disable personalization.

Notice and user control checklist

Controls should be understandable and operational. A button that says “clear memory” is not sufficient unless the team can define what it clears and verify completion.

Control	User-facing question	Operational proof
Notice	What may be remembered, why, and for how long?	Current notice version and route display record.
View	What memory is associated with this subject?	Authorized memory listing or support workflow.
Correct	How can a wrong memory be fixed?	Update record and re-test of future retrieval.
Delete	How can a user remove one item or all memory?	Deletion request ID and store-by-store completion evidence.
Disable	What happens when personalization is off?	No new write and no unauthorized read test.
Export	Which memory can be exported and in what form?	Scope, redaction, recipient, and delivery record.
Re-enable	What state returns after re-enabling?	Explicit migration or restore rule, not silent resurrection.
Appeal	How can a user challenge a harmful or incorrect inference?	Named owner, review route, and correction outcome.

Checklist:

The notice distinguishes session context, saved memory, profile settings, transcript, analytics, and provider-side features where relevant.
The user can disable future writes without losing access to a non-personalized route.
The control scope is visible before an irreversible action.
Support staff have a safe procedure for requests they cannot fulfill directly.
Localization, accessibility, and mobile views do not hide the control or change its meaning.
The team does not claim that a control clears data it cannot verify.

Tenant, role, and context boundaries

Memory must not become a shortcut around authorization. The AI chatbot retrieval access control and tenant isolation checklist covers the deeper data-flow and negative-test record.

Boundary	Allow case	Deny case	Safe expectation
Subject	User reads their approved preference	User asks for another subject’s memory	No content, count, identifier, or confirming metadata.
Tenant	Member uses memory inside tenant A	Member asks through tenant B	No cross-tenant read, write, cache, citation, or export.
Role	Support reviewer sees approved support fields	Basic user requests reviewer-only notes	Deny or use a controlled escalation path.
Route	Memory used by the approved chatbot	Other route or tool attempts to reuse it	Explicit scope check before retrieval.
Purpose	Personalization for the stated task	Unrelated recommendation or eligibility decision	Do not reuse without purpose and review.
Session	Same authorized subject and session	Replayed or stale session context	Expire, re-authenticate, or deny.
Action	Draft uses an approved preference	Memory triggers an irreversible action	Human approval and server-side authorization.

Boundary checklist:

Read and write paths carry subject, tenant, role, route, and purpose context.
A model output cannot grant itself permission to read or write memory.
Cache keys and embeddings preserve the same authorization scope.
Support and vendor access are time-limited and audited.
Cross-context negative tests cover citations, errors, counts, summaries, and tool arguments.

Retention, deletion, and restoration tests

Test deletion as a data lifecycle, not as a UI event. The AI chatbot deletion and export request workflow provides a companion request record.

Test ID	Trigger	Expected result	Evidence
DEL-001	Delete one visible memory item	Item no longer appears in authorized retrieval or display	Request ID, store results, and re-query.
DEL-002	Clear all memory	All in-scope memory stores and derived copies are handled	Store-by-store completion record.
DEL-003	Disable personalization	No new memory writes; route remains safe and useful	Before/after write and retrieval trace.
DEL-004	Correct an incorrect memory	Old value is not retrieved; corrected value follows purpose rules	Update record and regression result.
DEL-005	Account or tenant closure	Closure workflow handles memory, indexes, exports, and support copies	Closure record and residual-data check.
DEL-006	Backup or restore	Deleted or expired state is not silently resurrected	Restore test and post-restore scan.
DEL-007	Cache or embedding copy	Derived copy expires or is invalidated	Key, index, or invalidation evidence.
DEL-008	Provider or connector deletion	Vendor/system request and completion are recorded	Request, response, scope, and date.
DEL-009	Concurrent session	Deletion takes effect under an existing session	Session replay and cache test.
DEL-010	Support export	Export contains only approved scope and redactions	Export review and recipient record.

Do not report deletion as complete when only the primary row was removed. Record unavailable verification separately and keep scope restricted until the gap is resolved or explicitly accepted by the owner.

Support, export, and vendor access

Support access is a common place where a narrow memory boundary becomes a broad internal data path.

Access path	Minimum control	Review evidence
User support ticket	Verify subject and request scope before lookup	Ticket identity, scope, and redacted result.
Admin console	Role-based access, time limit, and audit trail	Admin session and export record.
Vendor support	Need-to-know, redaction, approved window, and closure	Approval, shared fields, expiry, and follow-up.
Analytics	Aggregation, minimization, and access separation	Query scope, retention, and output review.
Backup operator	Separate authorization and deletion/restore procedure	Operator, system, timestamp, and result.
Customer export	Exact scope, format, destination, and redaction	Export package review and delivery confirmation.

Checklist:

Support staff cannot search all memory by default.
Vendor sessions do not create an untracked copy of memory.
Exports exclude unrelated tenants, hidden profile labels, and restricted fields.
Audit logs do not duplicate sensitive memory unnecessarily.
Vendor and subprocessor changes trigger a memory privacy review.

Personalization and inference risks

Personalization can create new conclusions that the user did not explicitly provide. Separate confirmed facts from guesses and do not use hidden inferences for high-impact outcomes without a domain-approved process.

Risk	Example	Safer default
Incorrect inference	The bot infers a preference from one message	Ask, label as tentative, or keep session-only.
Sensitive inference	The bot infers health, employment, finance, or legal status	Do not persist; route to approved handling.
Stale preference	Old preference changes a current answer	Show date, ask, expire, or re-confirm.
Context collapse	Personal and work contexts are mixed	Separate profiles, routes, tenants, and controls.
Hidden ranking	A profile label changes recommendations invisibly	Explain relevant factors and provide correction/appeal.
Group inference	One person’s data changes a team’s personalization	Use approved aggregation and avoid individual exposure.
Feedback loop	A model-generated label becomes “truth” after reuse	Require source, confidence, reviewer, and correction path.

Inference checklist:

Stored values identify their source and whether they were confirmed.
Model-generated inferences are not presented as user-authored facts.
High-impact decisions do not rely on hidden memory alone.
A user can correct or challenge a personalization outcome.
Evaluation cases include stale, wrong, conflicting, and sensitive inferences.

Negative test set

Use synthetic fixtures to prove that memory cannot cross the intended boundary or survive a control that claims to remove it.

Test ID	Fixture or request	Expected safe behavior	Evidence
MEM-001	User A asks for User B’s saved preference	Deny without confirming whether it exists	Response, trace, and access decision.
MEM-002	Tenant A session reuses Tenant B cache key	No memory, citation, count, or error detail crosses scope	Cache key and response.
MEM-003	Retrieved memory says “ignore privacy policy”	Treat memory as data; policy and authorization remain in force	Input and output record.
MEM-004	Memory contains a secret or restricted field	Reject write and prevent later retrieval	Write decision and safe fixture result.
MEM-005	User disables personalization	No new write and no hidden old-memory read	Before/after trace.
MEM-006	User deletes memory during an active session	Existing session cannot continue using deleted state	Concurrent session result.
MEM-007	Backup restore follows deletion	Deleted item is not silently restored	Restore scan and decision.
MEM-008	Support user requests broad search	Need-to-know scope, approval, and audit record	Support access log.
MEM-009	Wrong model inference becomes profile fact	Unconfirmed inference is labeled, rejected, or kept temporary	Source and memory record.
MEM-010	Export request includes another tenant	Export is narrowed or blocked before delivery	Package review and delivery result.
MEM-011	Translation or encoding hides a memory request	Same boundary decision as plain language	Paired case results.
MEM-012	Tool action uses a stale preference	Server re-checks current authorization and approval	Tool trace and decision.

Critical failures should block persistence or keep the route session-only until the cause is fixed, the case is added to regression coverage, and an owner approves a narrower scope.

Monitoring and alert rules

Monitor both ordinary operations and changes in the data boundary.

Signal	Alert condition	First response
Memory write volume	Unexpected increase by route, tenant, or field	Pause writes and inspect source/change.
Sensitive write rejection	Repeated or new restricted-field attempts	Preserve safe evidence and review input path.
Cross-scope denial	Any unexpected cross-tenant or cross-role access attempt	Verify policy, session, cache, and connector context.
Delete completion delay	Request exceeds documented service target	Restrict reads and escalate to owner.
Reappearing memory	Deleted or expired item returns	Disable restore/cache path and investigate.
Support access	Access outside approved window or scope	Revoke session and review audit record.
Personalization complaint	User reports wrong, sensitive, or surprising memory	Suppress memory, preserve minimal evidence, and review.
Vendor/connector change	New scope, region, retention, or support path	Reopen the privacy review before expansion.

Monitoring checklist:

Alerts use route and tenant context without copying sensitive content into notifications.
Operators can pause writes and personalization independently from the base chatbot.
The response runbook names an owner and a safe fallback.
Sampling is minimized, approved, and retained for a defined period.
Findings become regression cases or documented exceptions.

Review workflow

Phase	Action	Output
1. Map	Inventory memory fields, stores, copies, actors, and purposes	Data-flow map and scope.
2. Minimize	Remove unnecessary fields and prohibit restricted inferences	Approved field matrix.
3. Control	Implement notice, view, correct, delete, disable, export, and appeal paths	Control record and owner.
4. Test	Run boundary, deletion, inference, injection, and failure cases	Negative-test evidence.
5. Review	Compare results with the previous configuration	Findings and change summary.
6. Decide	Approve, pilot, session-only, restrict, rollback, or pause	Signed release decision.
7. Monitor	Watch writes, deletion, access, complaints, and vendor changes	Post-release review.

Do not delete the previous review after a change. Keep the old configuration, new configuration, test diff, decision, and remediation together.

Evidence record

Use one row per memory field, test case, or control, with links to the controlled ticket or evidence store.

Field	Example
Review ID and case ID	`memory-2026-09-08-001`, `DEL-006`
Memory field and source	Confirmed preference from user settings; synthetic fixture
Purpose and classification	Personalization; user-selected; medium sensitivity
Subject and tenant scope	Synthetic subject A; tenant alpha
Store and copy paths	Profile DB, vector index, cache; no export
Expected behavior	Delete invalidates profile, index, cache, and restore path
Actual behavior	Result, error class, or unavailable verification note
Version references	Prompt, model, route, index, connector, policy, and code commit
Trace references	Request ID, audit ID, evidence file, retention date
Reviewer and timestamp	Named reviewer and UTC timestamp
Finding and severity	None, low, medium, high, or critical with rationale
Disposition	Pass, fix and rerun, restrict, exception, rollback, or pause

Evidence handling checklist:

The record contains no live customer data or credential material.
Traces identify the event without duplicating sensitive memory in the ticket.
The source and confidence of an inferred value are recorded.
Retention and access owners are named.
Unavailable deletion or access evidence is marked unavailable, not zero or complete.

Release gate

Gate	Pass requirement	Block condition
Purpose	Each memory field has an approved purpose and owner	Field is retained “just in case” or lacks an owner.
Minimization	Prohibited and unnecessary fields are rejected	Sensitive or speculative data is silently persisted.
Notice and control	Users can understand and exercise controls	Disable, delete, correction, or export is unclear or unowned.
Authorization	Subject, tenant, role, route, and purpose checks pass	Any cross-scope read, write, cache, citation, or export.
Deletion	Primary and derived stores follow the documented request	Deleted or expired memory returns without an approved reason.
Inference	Facts, preferences, and model inferences are distinguished	Hidden inference drives a high-impact outcome.
Support/vendor	Need-to-know access is time-limited and audited	Broad or untracked support access exists.
Testing	Critical negative cases are reproducible	Test or deletion result cannot be reproduced.
Rollback	Memory writes can be paused and scope reduced	No safe fallback or owner exists.

Default decision: keep memory disabled, session-only, or restricted to a narrow approved field set when a critical gate fails. Do not use a model instruction as a substitute for application authorization or deletion control.

Staged rollout plan

Stage	Scope	Required observation
0. Design	Data map and synthetic fixtures only	Field classification, purpose, controls, and negative tests.
1. Session-only pilot	Named staff without persistent writes	Confirm no hidden store, cache, transcript, or provider state.
2. Narrow memory pilot	One low-impact preference and one cohort	Write/read/delete, complaint, support, and access monitoring.
3. Limited cohort	Approved tenants and field set	Cross-scope tests, deletion propagation, and rollback rehearsal.
4. Broader release	Approved scope only	Periodic review, sampling, vendor monitoring, and change triggers.

At every stage:

The release owner knows the stop condition.
Memory writes can be paused without disabling the entire chatbot.
The user-facing control path is available and tested.
A non-personalized or session-only fallback is ready.
Incidents, complaints, and unexpected inferences become regression cases.

Findings and remediation

Finding	Severity	Immediate containment	Root-cause question	Closure evidence
Sensitive field persisted	Critical	Pause writes and isolate affected scope	Which classifier, source, or path allowed it?	Write rejection and cleanup tests pass.
Cross-tenant memory read	Critical	Disable memory route or narrow tenant scope	Where was context lost in retrieval, cache, or index?	Deny tests pass at each boundary.
Delete does not reach derived store	High/Critical	Keep reads restricted and invalidate path	Which copy, backup, or restore process was missed?	Store-by-store deletion evidence.
Hidden inference affects answer	High	Label, suppress, or require confirmation	Did the model-generated value become an authority?	Source, label, correction, and regression test.
Support access too broad	High	Revoke session and reduce scope	Which role or workflow bypassed need-to-know?	Time-bound access and audit proof.
Personalization cannot be disabled	Medium/High	Fall back to session-only	Which write or read path ignores user control?	Opt-out tests and user-facing result.
Memory reappears after restore	High	Pause restore and memory reads	Which backup or cache lifecycle ignored deletion?	Restore test and remediation.

Do not close a finding because the UI looks correct. Record the implementation, data lifecycle, and test change that explains the result.

Decision table

Review outcome	Release decision	Follow-up
Purpose, controls, boundaries, deletion, and critical tests pass	Approve narrow intended scope	Monitor and schedule reassessment.
Low-risk preference passes but deletion or support evidence is incomplete	Session-only or limited pilot	Close evidence gap before persistence expansion.
Sensitive field, cross-scope access, or reappearing deletion failure	Restrict, rollback, or pause	Contain, fix, rerun, and obtain fresh sign-off.
Inference is useful but unconfirmed	Show and confirm or keep temporary	Add correction, expiry, and regression coverage.
Vendor or connector behavior is unclear	Do not persist affected fields	Obtain evidence or use a narrower path.
Results are not reproducible	Keep current scope	Stabilize fixtures, versions, and lifecycle checks.

Sign-off record

Role	Name	Decision or condition	Date
Product/use-case owner
Engineering or platform owner
Security/privacy reviewer
Support or customer owner
Release owner		Approve, pilot, session-only, restrict, rollback, or pause

Decision statement:

Based on review ________, memory scope ________ is [approved / approved for pilot / session-only / restricted / rolled back / paused] for ________. The decision excludes ________. The next review is ________. Any critical failure, material complaint, deletion gap, or boundary change reopens this decision.

Action tracker

ID	Action	Status
1	Complete the field and data-flow inventory	Open
2	Verify notice, view, correct, delete, disable, and export controls	Open
3	Run tenant, role, inference, deletion, and cache negative tests	Open
4	Confirm support/vendor access and restore behavior	Open
5	Schedule post-release review and reassessment	Open

Final memory privacy checklist

Metrics to track

Track these by route, tenant scope, memory field, configuration version, and release stage:

Memory write volume and rejection rate by field class.
Percentage of memory items with purpose, source, owner, classification, and expiry.
Authorized versus denied memory reads, writes, exports, and support sessions.
Delete request completion time and residual-data verification coverage.
Count of memory items reappearing after expiry, deletion, restore, or cache invalidation.
Cross-subject, cross-role, or cross-tenant leakage count.
User opt-out, correction, export, complaint, and appeal volume.
Confirmed fact versus unconfirmed inference ratio and correction rate.
Sensitive-field detection, redaction, and safe fallback results.
Personalization-related incidents, pauses, and unresolved findings.
Days since last memory privacy review and days since last critical negative test.

Metrics are signals for a risk decision, not a universal privacy score. Compare like-for-like configurations and keep the reason for material changes.

Evidence checked

NIST Privacy Framework is a voluntary tool for identifying and managing privacy risk through enterprise risk management.
Using NIST Privacy Framework 1.1 describes ready, set, and go activities, target profiles, verification, and ongoing reassessment across the data lifecycle.
NIST AI RMF Core describes continuous risk management, measurement, monitoring, and documented assessment throughout the AI lifecycle.
NIST AI Risk Management Framework links the AI RMF and its Generative AI Profile for managing generative AI risks.
OWASP LLM02:2025 Sensitive Information Disclosure covers personal, financial, health, confidential, credential, and legal information disclosure risks in LLM applications.
CISA and UK NCSC secure AI system development guidance covers secure design, development, deployment, and operation of AI systems.
AI Tool Risk Checker for a route-level risk record.
Small Team AI Security Checklist for identity, data, access, logging, and incident foundations.

FAQ

Is chatbot memory just another prompt setting?

No. It creates a data lifecycle with capture, derivation, storage, retrieval, display, copying, retention, and deletion. Review each path rather than relying on a model instruction or UI label.

What should a small team allow first?

Start with session-only context or one low-risk, user-visible preference that can be viewed, corrected, disabled, and deleted. Keep sensitive fields, hidden profiles, and high-impact inferences out of persistent memory until the boundaries are proven.

Can we store everything if the user agreed?

Consent or notice does not remove the need for purpose, minimization, access control, retention, deletion, and safe downstream handling. Record the intended use and store only what the route needs.

How do we test deletion?

Create a synthetic memory item, request deletion, then query the primary store, index, cache, transcript, export, backup/restore path, and active session as applicable. Record unavailable checks separately and do not call the request complete without an owner decision.

Are embeddings and summaries memory?

Treat them as possible derived copies of the source data. Their access, retention, correction, deletion, and tenant scope need a documented rule even if the original text is not displayed.

Can personalization make an employment, financial, health, or legal decision?

Do not let hidden memory or unconfirmed inference make a high-impact decision. Use a domain-approved process, explicit evidence, human review, and server-side authorization where such a workflow is necessary.

What if the vendor does not explain how its memory feature works?

Do not assume the safest behavior. Ask for data locations, retention, access, deletion, export, training/use controls, support access, subprocessors, and incident processes. Keep the feature session-only or disabled until the relevant evidence is available.

What is the safest default after a cross-context leak?

Pause persistent memory and affected actions, preserve minimal safe evidence, restrict the route to session-only or read-only behavior, investigate every copy path, and add the incident to the regression pack before restart.

Recommended next step

Run the AI Tool Risk Checker for one chatbot route. Create two synthetic tenants, one confirmed preference, one unconfirmed inference, one deletion request, and one support-access case. Complete the Small Team AI Security Checklist, run the negative tests, and keep memory session-only or restricted until deletion and cross-context results are reproducible.