AI Policy

1. Purpose

This AI Policy establishes governance, privacy, security, and user-transparency requirements for Burr’s optional artificial intelligence features.

Burr’s current v1 AI features are designed to organize products and assist with shopping lists. They are not designed or authorized to classify users, infer health status, identify health-care seekers, diagnose users, build health profiles, make advertising decisions, or process consumer health data in Burr’s ordinary operations. Burr treats shopping items, task titles, categories, store types, and AI prompts as user-directed product labels and list-building inputs, not as health-status data, and must not use, analyze, or process those inputs to determine, characterize, or infer any consumer’s physical or mental health status.

2. Scope

This Policy applies to Burr’s AI-powered item categorization, list generation, related prompts, AI-generated outputs, AI service-provider integrations, AI metadata, consent records, and any future artificial intelligence or automated feature that processes Burr user content or operational data.

This Policy applies to the Managing Member, any emergency administrator, contractors, service providers, or other personnel who design, deploy, maintain, support, review, or respond to incidents involving Burr AI features.

3. Policy Principles

• User choice. AI features must be optional and subject to user consent or feature enablement.
• Data minimization. Burr must send only the item, store type, task, category, and prompt content reasonably necessary to provide the AI feature.
• No identity transfer. Burr must not send email addresses, account identifiers, household identifiers, location data, purchase-history identifiers, subscription information, live device coordinates, or any other persistent unique identifier that could link an AI request to a user to AI providers for current v1 AI features.
• No health inference. Burr must not use AI to identify health-care seekers, infer health status, diagnose users, create consumer health profiles, or process shopping items, task titles, categories, store types, household activity, purchase history, or AI prompts as consumer health data in current ordinary operations.
• No advertising use. Burr must not use AI features or AI outputs for advertising, targeted advertising, cross-context behavioral advertising, or ad-network disclosures.
• Human accountability. AI-generated outputs are assistive only and must not be treated as professional advice or as a substitute for user judgment.
• Security and auditability. AI-related data flows, consent records, vendor terms, incident records, and review evidence must be maintained consistently with Burr’s WISP and Incident Response Plan.

4. Approved AI Uses

Burr may use AI only for approved product-supporting functions, including product-level categorization, shopping-list assistance, and list-generation support requested or enabled by the user. Approved AI uses must remain limited to organizing items, store types, tasks, categories, and user prompts in support of Burr’s ordinary grocery, shopping-list, task, and coordination functions.

Examples of approved AI uses include:

• Suggesting a product category for a user-entered shopping item, such as categorizing “milk” as dairy or “paper towels” as household supplies.
• Helping generate a shopping list from a user-provided prompt, such as “items for a weekend barbecue” or “basic pantry staples.”
• Organizing user-entered task or item text into practical list groupings, such as produce, household goods, or errands.
• Assisting with list cleanup, including de-duplicating similar item entries, standardizing item wording, or suggesting clearer item labels.
• Providing product-level suggestions that help users manage ordinary shopping, task, and household coordination activities without evaluating the user or inferring health status.
• Supporting quota enforcement, save retry, and idempotency functions through limited operational metadata that does not include prompt text or generated list text.

Any materially new AI feature, new AI provider, new category of AI input, new retention practice, or new AI use involving location, purchase history, household activity, subscription records, or sensitive personal information requires documented privacy, security, and legal review before launch.

5. Prohibited AI Uses

• Using AI to classify users, determine eligibility, evaluate users, or make decisions producing legal or similarly significant effects.
• Using AI to infer health status, identify health-care seeking, diagnose users, create health profiles, or characterize Burr’s current ordinary operations as consumer health data processing without counsel approval.
• Sending user email addresses, account identifiers, location data, household identifiers, purchase-history identifiers, subscription information, live device coordinates, persistent unique identifiers, or other unnecessary personal information to AI providers.
• Using AI outputs for advertising, ad targeting, cross-context behavioral advertising, resale, or unrelated analytics.
• Training Burr-owned models or third-party models on Burr user content unless separately approved through documented legal, privacy, and security review.
• Using AI features for emergency, medical-device, medication-management, childcare-safety, life-support, or other safety-critical purposes.
• Deploying an AI feature that materially changes Burr’s no-consumer-health-data posture without prior counsel review and any legally required notice, consent, authorization, or policy update.

Examples of prohibited AI uses include:

• Asking AI to determine whether a user is pregnant, managing a medical condition, seeking health care, or likely to need health-related products based on shopping items, tasks, locations, or purchase history.
• Using AI to score, rank, segment, or profile users for eligibility, pricing, subscription offers, risk, trustworthiness, or similar user-level decisions.
• Sending a user’s email address, account identifier, household identifier, saved location coordinates, purchase history, subscription status, or live device coordinates to an AI provider for categorization or list generation.
• Using AI-generated categories or list content to target advertisements, build marketing audiences, sell or share personal information, or support cross-context behavioral advertising.
• Using household activity, shared lists, proximity alerts, or store-location information to infer sensitive attributes or health-related behavior about a user or household member.
• Retaining user prompts or AI-generated list text after delivery for model training, unrelated analytics, product personalization, or future profiling.
• Using AI outputs as medical, legal, financial, safety, emergency, medication-management, childcare, or other professional or safety-critical advice.
• Launching a new AI feature that uses purchase history, saved locations, household activity, or sensitive personal information without documented privacy, security, and counsel review.

6. Data Handling and Retention

AI list-generation prompts and AI-generated list text are processed in real time and are not stored by Burr after delivery, except that Burr may retain limited rejected-prompt feedback when a user submits feedback regarding a rejected prompt, consistent with Burr’s Privacy Policy. Burr may retain limited AI list-generation metadata for operational purposes, including generation identifiers, quota status, timestamps, save retry or idempotency identifiers, and an internal account reference used only for quota enforcement and save retry. Any AI quota identifier may be temporary, one-way hashed, tokenized, or otherwise structured to reduce linkability; it must remain an internal Burr account reference, must not be transmitted to Google Gemini or any successor AI provider, and must not include prompt text or generated list text. This metadata must not be used to determine, characterize, or infer health status and is retained for no longer than 90 days, or deleted sooner upon account deletion.

Where feasible, quota-enforcement identifiers and other AI operational identifiers should be ephemeral, one-way hashed, tokenized, or otherwise structured to reduce linkability after the AI request completes. Burr must not correlate AI operational metadata with item titles, prompt text, generated list text, household activity, purchase history, location data, or subscription records for profiling, advertising, health-status analysis, or unrelated analytics.

AI-related consent records may include event type, consent text version, text hash, HMAC email hash, timestamp, IP address, and user agent. Core consent metadata may be retained for legal compliance, consent verification, dispute response, audit, and fraud-prevention purposes. Device-identifying consent fields must be redacted after seven years or upon account deletion, whichever occurs first, consistent with Burr’s Privacy Policy and WISP.

7. User Consent, Transparency, and Controls

Users must be told, in clear and accessible language, that Burr’s optional AI features use Google Gemini or any approved successor AI provider to categorize items and assist with lists. The disclosure must explain the categories of content sent to the AI provider; the categories of information not sent, including email addresses, account identifiers, location data, household identifiers, purchase-history identifiers, subscription information, and persistent unique identifiers; the purpose of processing; retention limits; the treatment of prompts and item titles as user-directed product labels and list-building inputs; and how users may disable AI features.

Users may disable AI features at any time through Settings > Profile > Privacy > AI Features or any successor control. When AI features are disabled, Burr must not send user content to third-party AI services for those disabled features.

8. Vendor and Security Requirements

AI providers must be reviewed before use to confirm the business purpose, data categories, data processing terms, security controls, retention practices, breach-notice commitments, sub-processor considerations, and Privacy Policy or Terms updates required before launch.

AI provider review must confirm that Burr does not permit the provider to use Burr prompts, item titles, generated list text, or related metadata to build user profiles, identify Burr users, infer health status, advertise, train models unless separately approved, or use the content for purposes beyond real-time processing, safety monitoring, security, abuse prevention, and other expressly approved service-provider functions.

AI provider credentials, API keys, and related secrets must be stored in approved secrets-management locations, account-managed secrets, or encrypted repository storage using approved encryption tooling, and must not be committed in plaintext or unencrypted form. Access to AI provider consoles, logs, credentials, consent records, and related administrative tools must be reviewed at least quarterly and promptly after any administrator, contractor, emergency administrator, or vendor relationship change.

Where feasible, AI traffic should be logged at an operational level sufficient to confirm feature usage, quota status, errors, and provider availability without storing prompt content, generated text, item titles, unnecessary identifiers, persistent unique identifiers, or sensitive personal information. Burr should also periodically confirm that provider logs, safety logs, request metadata, and related service records do not create unnecessary linkability between AI requests and identifiable Burr users.

9. Monitoring, Testing, and Change Management

AI-related code paths must be reviewed before deployment for data minimization, input validation, error logging, prompt retention, consent gating, and consistency with Burr’s Privacy Policy, Terms of Service, AI consent, WISP, and Incident Response Plan.

Material changes to AI processing, provider integrations, prompt content, metadata retention, logging, consent flows, or user-facing disclosures must be documented before deployment, reviewed for privacy and security impact, and archived with release or commit evidence. Emergency changes may be deployed first to contain active risk but must be documented promptly afterward.

10. Incident Response

Any suspected security, privacy, AI-provider, prompt-exposure, logging, consent, or unauthorized-disclosure incident involving AI features must be handled under Burr’s Incident Response Plan. The incident record should identify affected AI inputs, outputs, metadata, provider logs, users, households, resident states, consent records, and whether identifiers excluded by this Policy were nevertheless transmitted or exposed.

Incident communications must avoid unsupported admissions that consumer health data, a health breach, the FTC Health Breach Notification Rule, or Washington’s My Health My Data Act applies unless counsel has approved that classification based on the incident facts. Counsel must approve any user, regulator, processor, platform, substitute, media, or public communication involving an AI incident.

11. Review Cadence and Ownership

The Managing Member is the owner of this Policy and is responsible for maintaining AI governance evidence, coordinating legal review when required, and ensuring material AI-related changes are reflected in the Privacy Policy, Terms of Service, AI Features Consent, WISP, Incident Response Plan, and related compliance runbooks.

This Policy should be reviewed at least quarterly with the WISP review cycle, annually during the consumer-facing privacy review, before any materially new AI feature or provider is launched, after any AI-related security or privacy incident, and whenever applicable law, provider terms, or Burr data flows materially change.

12. AI Risk Management

Burr must manage AI risk through a documented lifecycle that identifies foreseeable risks before launch, applies appropriate privacy and security controls during operation, monitors for drift or misuse, and updates governance materials when AI features, vendors, data flows, or legal requirements change.

AI risk reviews should be recorded in a risk register that identifies the AI feature, use case, input data categories, output type, provider, applicable disclosures, risk classification, required controls, residual risk, owner, approval date, next review date, and evidence location.

• Pre-launch risk review. Before deploying a new or materially changed AI feature, Burr should document the business purpose, expected user benefit, input data categories, output type, provider, retention period, user disclosures, consent controls, potential sensitive-data implications, and whether counsel review is required.
• Risk classification. AI uses should be classified as low, moderate, or heightened risk based on data sensitivity, user impact, use of identifiers, location or household context, purchase-history involvement, retention practices, provider changes, and whether outputs could be misunderstood as professional or safety-critical advice.

Risk classifications should be based on documented criteria. A low-risk AI use is limited to product-level item organization without identifiers or sensitive context. A moderate-risk AI use involves new prompts, new output types, changed retention, or changed provider terms but does not involve identifiers, location, household context, purchase history, or health-indicative use cases. A heightened-risk AI use involves sensitive personal information, location, household context, purchase history, subscription records, model training, prompt retention, health-indicative use cases, or any use that could affect legal or similarly significant user outcomes.

• Control mapping. Each AI use should be mapped to required controls, including consent gating, data minimization, identifier exclusion, prompt/output retention limits, vendor terms review, secrets protection, access controls, logging limits, user disablement controls, and incident-response procedures.
• Human oversight. AI outputs must remain assistive. Burr should design user experiences so users can review, edit, ignore, or delete AI-generated suggestions before relying on them.
• Misuse prevention. Burr should use product design, disclosures, and technical controls to discourage prohibited uses, including health inference, user profiling, advertising, safety-critical reliance, and professional-advice reliance.

Before AI content is sent to a provider, Burr should use reasonable technical or procedural controls to prevent prohibited input categories from being included, including email addresses, account identifiers, household identifiers, precise location data, purchase-history identifiers, subscription records, live device coordinates, persistent unique identifiers, and other unnecessary personal information. Burr should also maintain technical or procedural controls that prevent AI features from using item titles, shopping history, household activity, or prompts to determine, characterize, or infer a user’s physical or mental health status.

• Monitoring and validation. Burr should periodically review AI feature behavior, error patterns, user reports, provider notices, logging practices, retained metadata, and sample outputs on a risk-based cadence to confirm that each feature continues to operate within approved limits. Heightened-risk AI uses should be reviewed before launch, after material changes, after relevant provider notices, and after any AI-related incident.

AI release testing should verify that prompt text and generated list text are not written to databases, logs, analytics tools, crash reports, support systems, backups, or provider-facing metadata outside the approved real-time processing flow.

Burr should test AI outputs for foreseeable error patterns, including incorrect item categorization, unsafe or professional-advice framing, hallucinated product attributes, over-personalized suggestions, and responses that could imply health, eligibility, or safety conclusions about a user.

User reports involving AI errors, unexpected outputs, suspected sensitive inferences, unwanted personalization, or disabled-AI behavior should be reviewed as part of AI monitoring and escalated when they indicate a prohibited use, inaccurate disclosure, retention issue, or incident-response trigger.

• Escalation triggers. Counsel and privacy/security review are required if AI processing begins to involve new personal information categories, location data, household identifiers, purchase history, subscription records, persistent unique identifiers, prompt or output retention, health-indicative use cases, model training, materially different provider terms, or any provider logging or metadata practice that could reasonably link AI requests to identifiable users.

Burr should re-review an AI provider when the provider materially changes its data-use terms, retention practices, logging practices, sub-processors, security controls, geographic processing locations, breach-notice commitments, or model-improvement restrictions.

Low-risk AI uses may be approved by the Managing Member after documenting the required control mapping. Moderate-risk AI uses require documented privacy and security review. Heightened-risk AI uses require Managing Member approval after counsel review and any required updates to user disclosures, consent text, the Privacy Policy, Terms of Service, WISP, Incident Response Plan, or related runbooks.

• Residual-risk acceptance. Any material risk that is not fully mitigated must be documented, assigned an owner, given a review date, mapped to compensating controls, and accepted only by the Managing Member after legal or security consultation where appropriate. Heightened-risk residual risks should not be accepted until counsel has reviewed whether user disclosures, consent text, retention practices, vendor terms, or incident-response procedures must be updated.

Each AI feature should have a documented rollback or disablement path that allows Burr to promptly suspend the feature if prohibited inputs are detected, provider terms change materially, prompt or output retention is discovered, user disclosures become inaccurate, or an AI-related security or privacy incident is suspected.

• Evidence retention. Risk assessments, approval notes, vendor reviews, consent text versions, control mappings, test results, release evidence, provider notices, monitoring results, user-report escalations, residual-risk acceptances, and incident records should be retained with the WISP or legal evidence archive so Burr can demonstrate reasonable AI governance practices.

13. Key Compliance Requirements

• Consent and user control. AI features must remain optional, subject to user enablement or consent, and capable of being disabled through Settings > Profile > Privacy > AI Features or a successor control.
• Transparent disclosures. User-facing disclosures must describe what AI features do, what content is sent to the AI provider, what categories of information are not sent, the purpose of processing, retention limits, and how users may disable AI.
• Data minimization. Burr may send only the item, store type, task, category, and prompt content needed to provide the AI feature and must not send unnecessary personal information.
• Identifier exclusion. Burr must not send email addresses, account identifiers, household identifiers, location data, purchase-history identifiers, subscription information, live device coordinates, persistent unique identifiers, or any identifier that could link an AI request to a user to AI providers for current v1 AI features.
• No consumer health data processing. Burr must preserve its current no-consumer-health-data posture by treating shopping items, task titles, categories, store types, and prompts as user-directed product labels and list-building inputs, and by not using AI features or metadata to determine, characterize, or infer health status, identify health-care seekers, diagnose users, or create health profiles unless counsel approves a different classification based on changed facts, features, data flows, or legal requirements.
• No advertising or profiling. AI features and AI outputs must not be used for advertising, targeted advertising, cross-context behavioral advertising, user profiling, eligibility decisions, or legal or similarly significant automated decisions.
• Retention limits. Prompt text and generated list text must not be stored after delivery, except for limited rejected-prompt feedback submitted by a user consistent with Burr’s Privacy Policy; limited AI operational metadata may be retained only for approved purposes and for the approved retention period.
• Consent and audit evidence. Consent text versions, text hashes, HMAC email hashes, timestamps, and related audit records must be maintained consistently with Burr’s Privacy Policy, WISP, and consent-record retention schedule.
• Vendor review. AI providers must be reviewed for business purpose, data categories, processing terms, security controls, retention practices, logging practices, metadata practices, model-improvement restrictions, breach-notice commitments, sub-processors, profile-building restrictions, and required legal-document updates before use.
• Security controls. AI credentials, API keys, and related secrets must be protected, access must be reviewed at least quarterly, and operational logging must avoid prompt text, generated text, item titles, unnecessary identifiers, persistent unique identifiers, and sensitive personal information where feasible.
• Change management. Material AI changes must be documented, privacy/security reviewed, legally reviewed where appropriate, and archived with release or commit evidence before deployment unless emergency containment requires prompt action.
• Incident response. Suspected AI-related security, privacy, prompt-exposure, logging, provider, consent, or unauthorized-disclosure incidents must be handled under Burr’s Incident Response Plan, with counsel approval before external notices or public communications.

14. Contact Information

Legal inquiries: [email protected]
Privacy inquiries and rights requests: [email protected]
Account or technical support: [email protected]
Mail: Adaely Group LLC, Attn: AI Policy, 522 W. Riverside Ave, Ste N, Spokane, WA 99201