Local-first by design.

OpenMindAI Desktop and Mobile Applications

Legal, Privacy, Responsible AI, Security & Microsoft Store Compliance Pack

• Publisher / Developer: Md Shahanur Islam Shagor / OpenMindAI

• Product: OpenMindAI Desktop and Mobile Applications

• Effective date: 3 September 2026

• Primary website: https://openmindai.vercel.app/

• Contact: https://openmindai.vercel.app/contact

• Primary distribution context: Microsoft Store and supported desktop and mobile distribution channels

Important publication note: This document is a comprehensive policy and compliance template prepared for OpenMindAI. It is designed to support transparent product practices and Microsoft Store submission, but it is not a substitute for advice from qualified counsel in every country where the application is offered. Before public release, verify that the product’s actual behavior matches every statement in this document and update any feature-specific language that differs from the released build.

Document Control and Intended Use

This pack consolidates the public-facing and internal governance language that privacy-conscious AI desktop and mobile applications commonly need: a full Privacy Policy, Terms of Use, End User License Agreement terms, Responsible AI and Content Safety rules, security and data-governance commitments, Microsoft Store compliance notes, data-retention and permission matrices, and a short-form privacy notice that can be surfaced inside the application. The goal is to avoid contradictory policy fragments and to give users, store reviewers, support staff, and future contributors a single source of truth.

The document assumes an offline-first OpenMindAI architecture across desktop and mobile devices where supported. Compatible AI models may run locally on the user’s device, and conversation history or working data may be stored locally according to the platform, device capability, selected model, and user settings. It also anticipates optional network-enabled features such as model downloads, web search, update checks, remote integrations, or third-party AI services. Those optional features are treated separately because local processing and remote processing create different privacy consequences. A released build must never describe a network feature as local if data actually leaves the device.

Microsoft Store policy requires Win32 products that access personal information to maintain a privacy policy and to explain what personal information is accessed, collected, transmitted, used, stored, secured, disclosed, and controlled by users. Microsoft Store policy also requires products that contain live generative AI content to disclose generative AI use in metadata, declare it in Partner Center, comply with Store content rules, and give users a way to report inappropriate AI-generated content. This document includes language and checklists for those requirements.

The publisher should publish the Privacy Policy and Terms at stable HTTPS URLs before submission, link them from the application’s Settings/About area, and use the same core statements in Microsoft Partner Center. Material changes to data practices should be reflected in both the app and the hosted policy before or at the time the changed processing begins. A policy is only useful when it accurately represents the software.

Contents

• Privacy Policy

• Scope, identity and privacy principles

• Product architecture and data-flow model

• Categories of information and data

• Local storage and local AI processing

• Prompts, chats, generated outputs and memory

• Files, documents, images, audio and other user content

• Mobile application privacy and permission considerations

• Device, diagnostics, logs and telemetry

• AI model acquisition, verification and storage

• Network-enabled features, web search and third-party services

• Purposes of processing and legal bases

• Sharing, disclosures, processors and international transfers

• Data retention, deletion and backups

• Security safeguards

• User controls and privacy rights

• Region-specific privacy disclosures

• Children and age-appropriate use

• Automated processing and high-impact decisions

• Security incidents and policy changes

• Contact and complaints

• Terms of Use and End User License Agreement

• Acceptance and eligibility

• Software license and permitted use

• Acceptable Use Policy

• Responsible AI and content safety

• AI limitations, accuracy and professional-use warnings

• User content and intellectual property

• Third-party models, software and licenses

• Updates, availability, support and lifecycle

• Warranty disclaimer, liability and termination

• EULA and Microsoft Store and platform-specific terms

• Security, Governance and Store Compliance

• Privacy and security governance standard

• Microsoft Store compliance guidance

• Mobile app store compliance

• Release and certification checklist

• Data inventory, retention and permission tables

• User-facing short privacy notice

• Incident and privacy-request procedures

• Source references and maintenance notes

Privacy Policy

This Privacy Policy describes how OpenMindAI handles information when users install, configure, and use the OpenMindAI Desktop and Mobile Applications. The policy is intentionally written around data flows rather than marketing labels. “Offline,” “local,” “private,” and similar terms should be used only where the released software actually keeps the relevant data on the user’s device. Optional online features are covered independently so that users can make informed choices.

Scope, Identity and Privacy Principles

OpenMindAI is published and maintained by Md Shahanur Islam Shagor under the OpenMindAI product name. For purposes of this document, “OpenMindAI,” “we,” “us,” or “our” refers to the publisher responsible for the application and its published support resources. “You” or “user” refers to the person using the application. This Privacy Policy applies to the OpenMindAI desktop and mobile software, related update and model-delivery mechanisms operated by the publisher, and support interactions that expressly reference this policy. Separate websites, repositories, third-party model hosts, search providers, or external APIs may have their own privacy terms.

Our default privacy approach is data minimization. OpenMindAI should process only the information reasonably necessary for the feature the user has chosen. Where a task can be completed on-device, the preferred architecture is local processing. Where a network request is necessary or intentionally enabled, the application should make that distinction understandable and avoid silently transmitting unrelated content. Privacy-sensitive features should be opt-in where consent is an appropriate basis, and the user should be able to disable them without losing unrelated local functionality whenever technically practical.

The core privacy principles are: transparency about where data goes; purpose limitation; collection of the minimum information required; local-first storage where appropriate; reasonable retention periods; user control over deletion and sharing; secure handling of locally stored and transmitted information; separation of optional online services from offline functionality; and accountability through documented releases, permissions, dependencies, and policy updates. These principles are consistent with widely recognized privacy frameworks such as the GDPR principles of lawfulness, fairness, transparency, purpose limitation, data minimization, storage limitation, accuracy, integrity/confidentiality, and accountability.

Product Architecture and Data-Flow Model

OpenMindAI is designed as a desktop and mobile AI assistant that can run compatible language or multimodal models locally on supported computers, phones, and tablets. In a local workflow, a prompt is entered into the application interface, the selected local model processes that prompt through an installed runtime, and the generated output is returned to the interface. When a supported local model is selected, the prompt and output do not need to be sent to OpenMindAI servers merely for the local inference operation. If local history is enabled, conversation records may be written to a local application database so the user can reopen them later.

The application may also support optional network operations. Typical examples include downloading model files or runtimes, checking for software updates, opening links, using web search, connecting a third-party account, invoking a remote AI provider when the user explicitly configures one, retrieving documentation, or submitting a support or safety report. Each network operation should transmit only the data required for that specific function. The existence of a network connection does not mean all chats are uploaded; equally, the presence of local models must not be used to imply that every feature is offline.

A practical way to understand OpenMindAI data flow is to separate four zones. First, the local workspace contains user-selected storage, local models, application settings, logs, and conversation history. Second, the operating-system zone contains Windows, Android, iOS, or other supported platform permissions, file or media access, graphics and hardware information, notifications, and networking facilities. Third, the publisher-service zone may include update manifests, official downloads, documentation or support endpoints. Fourth, third-party zones may include model repositories, web search engines, identity providers, remote APIs, or links the user chooses to open. Data crossing from the local zone to any remote zone should be tied to an explicit feature and documented in the user interface or this policy.

Portable or user-selected storage does not eliminate privacy risk. A removable drive can be lost, copied, or connected to another computer. A local database can be accessed by malware or another account with sufficient operating-system privileges. Users should therefore protect their device account, enable full-disk or device encryption where appropriate, maintain secure backups, and avoid storing highly sensitive information in any AI system unless they have evaluated the risks.

Categories of Information and Data

Depending on how OpenMindAI is configured and which features are used, the application may handle several categories of data. The fact that the software can access a category does not mean the publisher automatically receives it. The most important distinction is whether information remains local, is transmitted to an OpenMindAI-operated endpoint, or is transmitted directly to a third-party service selected by the user.

• User content: prompts, chat messages, code, notes, generated responses, saved conversation titles, and any text pasted into the application.

• Files and documents: files the user intentionally opens, imports, analyzes, summarizes, converts, or generates. This may include document text, filenames, file paths, and metadata needed to perform the requested operation.

• Image and audio content: images the user selects for analysis or generation, microphone recordings when voice input is enabled, and generated media where supported.

• Configuration data: application settings, selected model, model path, storage root, language, performance profile, feature toggles, and integration settings.

• Device and runtime information: operating-system version, CPU/GPU capabilities, memory availability, architecture, application build information, runtime compatibility information, and similar technical details.

• Diagnostic information: local logs, error messages, crash traces, download status, integrity-check results, and performance information. Remote diagnostics should be collected only when explicitly implemented and disclosed.

• Network request data: IP address and ordinary connection metadata visible to a server when the app retrieves a model, checks for an update, performs a web search, or calls a third-party API.

• Support and safety-report data: information the user voluntarily sends when requesting support or reporting harmful, inappropriate, or unexpected AI-generated content.

• Account or integration data: tokens, identifiers, email address, profile information, or authorization scopes if the user connects an external service. Such data should be limited to what the integration requires.

OpenMindAI does not need to require users to provide sensitive personal data in order to perform ordinary local AI inference. Users should avoid entering passwords, private cryptographic keys, authentication secrets, government identifiers, confidential health records, financial account credentials, or other high-risk secrets into prompts unless they understand and accept the consequences of local storage and any optional remote service they have enabled.

Local Storage and Local AI Processing

Local AI processing is a central privacy feature of OpenMindAI. When a compatible model is installed and a local inference mode is selected, the application is intended to send the user’s prompt to the local model runtime on the same computer rather than to a hosted AI inference endpoint. The model output is generated on-device. This can reduce exposure to remote service providers, but local processing should not be described as anonymous or risk-free. The information still exists in computer memory during use and may be stored in local history, temporary files, caches, swap, backups, or diagnostic records depending on the operating system and configuration.

Conversation history may be stored in a local application database so users can reopen prior chats. Local history should be treated as user-controlled application data. The application should provide a practical method to delete individual conversations and, where feasible, clear all history. Uninstall behavior must be documented because Windows uninstallers may preserve user data intentionally to support reinstall, while a “delete all local data” function should remove the application-managed records the user reasonably expects it to remove.

Model files can be large and are normally stored separately from chat history. Deleting a model should not automatically delete conversation history unless the application explicitly says so. Conversely, deleting a conversation should not remove the model. Storage controls should show users which categories consume disk space and should avoid deleting files outside OpenMindAI-managed directories unless the user specifically selected them.

Where OpenMindAI offers a portable storage mode, the selected drive or folder becomes part of the user’s security boundary. OpenMindAI cannot prevent a user, administrator, backup program, antivirus product, forensic utility, or malware with sufficient access from reading unencrypted application files. If the application later introduces encryption-at-rest for local conversations, the policy and UI should be updated to explain the encryption scope, key handling, recovery limitations, and whether filenames, indexes, logs, or model metadata remain unencrypted.

Prompts, Chats, Generated Outputs and Memory

Prompts and generated outputs can contain personal information even when the user does not intentionally provide it. A code sample can contain an email address or API token; a document summary can reveal customer information; a generated response may repeat details provided earlier in a conversation. OpenMindAI therefore treats conversation content as user-controlled content rather than harmless telemetry. Local conversation content should not be repurposed for advertising, sale of personal information, or training a publisher-operated model unless the user has been clearly informed and an appropriate legal basis exists.

If OpenMindAI offers persistent memory, retrieval-augmented generation, knowledge bases, embeddings, or indexing, those features should be presented as forms of local or remote data processing rather than as invisible model behavior. A user should be able to understand what is being indexed, where the index is stored, how long it persists, and how to delete it. If embeddings are generated locally, the index can remain on-device. If a remote embedding provider is selected, relevant text may be transmitted to that provider, and the application should disclose this before the feature is used.

Generated output belongs to a special category because it is new content produced from model inference rather than a verbatim record of user input. Generated output may be inaccurate, fabricated, biased, incomplete, unsafe, or similar to existing protected material. Privacy risks can also arise when a model infers or invents information about real people. Users should not assume an AI-generated claim about an identifiable person is true, and they should verify such information before publication or consequential use.

OpenMindAI should not silently use private conversations to create public galleries, leaderboards, shared prompt libraries, or community datasets. Any future sharing feature must clearly identify what will become visible, to whom, for how long, and how the user can revoke or delete the shared content. Where Microsoft Store policy requires opt-in consent before publishing personal information to an outside service, the product should implement a clear in-product consent control rather than relying only on a general Terms link.

Files, Documents, Images, Audio and Other User Content

OpenMindAI may allow users to select files for summarization, question answering, conversion, code analysis, document generation, or similar tasks. File access should be user-initiated or limited to application-managed folders. The application should not crawl unrelated user directories or index the entire computer by default. When a file is processed locally, the file content can remain on the device. If a user chooses a feature backed by an external service, the relevant file or extracted content may need to be transmitted to that service and should be disclosed at the point of use.

Document metadata can itself contain personal information, including author names, organization names, tracked changes, comments, hidden text, revision history, file paths, or embedded objects. OpenMindAI should not promise that a generated or transformed document is metadata-free unless the specific export pipeline has been designed and tested for that purpose. Users publishing documents externally should review the output and use suitable metadata-scrubbing tools when confidentiality matters.

Microphone and camera capabilities are sensitive because audio, video, and images can contain biometric or identifying information. OpenMindAI should request desktop or mobile operating-system permissions only when the user invokes a feature that needs the capability, explain the feature’s purpose, and avoid background capture that is unrelated to an active user request. Voice recordings should remain local when using a local transcription pipeline; if a remote transcription service is enabled, audio may be transmitted to that service. The same principle applies to remote image analysis and image generation providers.

Clipboard access, drag-and-drop, screen capture, screenshots, or window-content analysis can expose information from other applications. These capabilities should be scoped to the user’s explicit action and should not be used as a hidden surveillance mechanism. The software should not capture passwords, payment details, private communications, or screen content in the background for analytics or model training.

Mobile Application Privacy and Permission Considerations

OpenMindAI mobile applications may use platform permissions that differ from the desktop application. Depending on the features included in a released build, these can include microphone access for voice input, camera access for image capture, photo or media-library access for user-selected images and files, document-picker access, notification permission, network access, local storage, and limited device information needed for compatibility or performance. OpenMindAI should request a sensitive permission only when the user starts or enables a feature that reasonably needs it.

• Microphone access should be used only for voice input, speech transcription, audio analysis, or another clearly presented audio feature initiated by the user.

• Camera access should be used only when the user chooses to capture an image, scan content, use a vision feature, or perform another camera-dependent action.

• Photos, media, and document access should be limited to content the user selects or to application-managed files where the mobile operating system allows that design. OpenMindAI should not silently scan the user’s entire photo library or storage.

• Notifications should be used for user-relevant application events such as completed downloads, generated results, update information, or other enabled reminders. Notification permission should not be treated as permission for advertising tracking.

• Network access may be required for model downloads, web search, updates, account integrations, support, remote AI providers, or other online features. Local-only features should not transmit prompts or files merely because the device has an internet connection.

• Background processing should be limited to functions allowed by the operating system and reasonably expected by the user. OpenMindAI should not use background execution to record audio, capture images, monitor other applications, or transmit private content without a clear feature need and appropriate user awareness.

• Mobile operating systems may display their own permission prompts, privacy indicators, battery controls, background restrictions, storage controls, and application-data deletion options. Users can review or revoke permissions through device settings. Revoking a permission may disable only the feature that depends on it.

• If a mobile platform or app store requires a privacy disclosure, data-safety form, permission declaration, tracking declaration, or similar metadata, the published answers must match the actual released mobile build and this policy.

OpenMindAI should follow the same privacy principle across desktop and mobile: local processing should remain local where the feature is designed to operate locally, optional online processing should be identifiable, and user content should not be transmitted for unrelated purposes.

Device, Diagnostics, Logs and Telemetry

OpenMindAI may need device information to choose a safe model, runtime, or performance profile. Examples include CPU architecture, GPU vendor and capabilities, available memory, storage availability, operating-system version, and application build number. When this information is used only locally for compatibility decisions, it does not need to be sent to the publisher. If a diagnostic or support feature transmits device details, the user should be informed about the categories transmitted and the purpose.

Local logs are useful for troubleshooting download failures, runtime errors, model-loading problems, GPU compatibility issues, and application crashes. Logs should avoid recording complete prompts, document contents, access tokens, passwords, or other secrets unless there is a compelling debugging reason and the user has been clearly informed. Where log redaction is technically feasible, secrets and personally identifying values should be masked by default.

OpenMindAI’s privacy-friendly default should be no behavioral advertising telemetry and no sale of personal information. If future versions introduce analytics, crash reporting, usage metrics, or experiments, the publisher should update this policy before deployment and should use privacy-preserving defaults. Analytics events should be narrowly defined, retained for limited periods, and separated from user content. A crash report should not automatically attach an entire conversation or document simply because it was open when the crash occurred.

Support bundles should be generated transparently. A user should be able to review, or at minimum be told, what types of files a diagnostic package contains before sending it. Where feasible, OpenMindAI should provide “copy diagnostic summary” and “open logs folder” functions so users can inspect the material. Support staff should request the minimum additional information needed to reproduce an issue.

AI Model Acquisition, Verification and Storage

OpenMindAI may download model files, tokenizers, inference runtimes, metadata, or related assets from official or third-party repositories. A model download request necessarily reveals ordinary network metadata such as the user’s IP address to the download host. The host may independently log those requests under its own privacy policy. OpenMindAI should identify the source of a model or runtime when practical and should not imply that a third-party model is authored, sponsored, or endorsed by OpenMindAI unless that relationship exists.

Model integrity is a security and privacy concern. A tampered model or runtime could create unexpected behavior or, in the case of executable components, security risk. The application should use authenticated HTTPS sources, verify checksums or signatures when they are available and maintained, avoid executing untrusted downloaded binaries without validation, and isolate models from executable update mechanisms. Users who manually import models accept additional risk and should be informed when a model is outside the publisher’s tested catalog.

Downloaded models can be several gigabytes in size and may be stored until the user removes them. The application should provide clear deletion controls and should not re-download a deleted model without a new user action unless the user has enabled an automatic model-management feature. A model file typically does not contain the user’s conversation history merely because it was used to generate responses; fine-tuning, training, or model-writing features would be different and would require additional disclosure.

Model licenses vary. Some models allow broad commercial use, some impose attribution or acceptable-use obligations, and some restrict particular uses. OpenMindAI should keep a machine-readable or human-readable model catalog that records model family, source, license, version or revision, approximate size, intended capabilities, and any relevant use restrictions. The presence of a model in the application should never be presented as a transfer of ownership of that model to the user or the publisher.

Network-Enabled Features, Web Search and Third-Party Services

Optional web search can send the user’s search query, or a query derived from the user’s prompt, to a search provider. A query may contain personal information if the user includes it. OpenMindAI should make web-enabled mode visible and should avoid sending full conversation history when only a short search query is necessary. Search results may be retrieved from third parties whose privacy and content practices are independent from OpenMindAI.

If OpenMindAI supports external AI providers, the user’s selected prompt, attachments, or conversation context may be transmitted to that provider as required by the provider’s API. The provider may process or retain the information according to the user’s account terms and the provider’s policy. OpenMindAI should not claim that a remote provider operates under the same local-only privacy model as an on-device model. API keys should be stored using reasonable platform protections and should never be intentionally included in analytics or support logs.

Account integrations such as cloud storage, email, calendars, code repositories, or identity providers should use the narrowest practical authorization scopes. The application should explain the purpose of each permission and provide a way to disconnect the integration. Revoking access through the third-party account is also recommended. OpenMindAI should not repurpose an authorization granted for one integration to access unrelated data.

Links displayed by the application may open external websites. Once a user leaves the application, that site controls its own collection of cookies, identifiers, form data, and browsing information. OpenMindAI cannot guarantee the accuracy, availability, security, or privacy practices of every external site returned by an AI model or search result. Users should inspect destinations before providing credentials or downloading software.

Purposes of Processing and Legal Bases

OpenMindAI processes information to provide the function the user requested, maintain local settings and history, download selected components, secure and troubleshoot the application, respond to support requests, comply with law, and protect users and the service from abuse. The exact legal basis depends on jurisdiction and feature. For many local operations, the publisher does not receive the information at all, so the user is primarily directing processing on their own device. For publisher-operated remote services, contractual necessity, legitimate interests, consent, or legal obligation may apply depending on the circumstances.

Where consent is relied upon, consent should be specific, informed, freely given where required, and capable of withdrawal. Disabling an optional analytics or remote-inference feature should stop new processing based on that consent, subject to limited retention needed for security, legal compliance, or previously completed transactions. Consent should not be bundled into an unrelated feature where the user has no meaningful choice.

Legitimate interests may include operating secure update infrastructure, preventing abuse, diagnosing failures, and maintaining the reliability of publisher-operated services. When legitimate interests are used as a basis, the publisher should consider the user’s reasonable expectations, sensitivity of the data, and whether a less intrusive method could achieve the same result. Highly sensitive data should not be collected merely because it may be technically useful.

Legal obligations may require preservation or disclosure of certain records in response to valid legal process, tax or accounting rules, security obligations, or regulatory requirements. OpenMindAI will not use the phrase “we never disclose data” because lawful disclosure can sometimes be mandatory. The more accurate commitment is that disclosures should be limited, documented, legally grounded, and proportionate to the request.

Sharing, Disclosures, Processors and International Transfers

OpenMindAI does not need to sell personal information or rent user conversation content as part of its local AI business model. The publisher should not disclose user content to advertising data brokers. Information may nevertheless be shared with service providers when a user chooses a network feature or when the publisher uses vendors for hosting, software distribution, security, support, or communication. Those providers should receive only the information needed for the service and should be subject to appropriate contractual or platform terms.

Third-party AI providers, model repositories, search engines, identity providers, and cloud services are not automatically sub-processors of the publisher in every situation. In some configurations the user may interact with them directly under the user’s own account or API key. The UI should distinguish publisher-controlled processing from user-configured third-party processing so users can understand who is responsible for the data flow.

International data transfers may occur when a remote service processes data in another country. Where GDPR, UK GDPR, or similar rules apply, an appropriate transfer mechanism may be required, such as an adequacy decision, standard contractual clauses, a recognized data-transfer framework, or another lawful safeguard. The applicable mechanism depends on the provider and the publisher’s legal establishment. The published privacy notice should be updated with vendor-specific transfer information once production providers are finalized.

The publisher may disclose information to law enforcement, courts, regulators, or other authorities where required by applicable law or valid legal process, and may disclose limited information when reasonably necessary to protect rights, security, or users. The publisher should scrutinize requests and disclose no more than legally required where it has discretion to do so.

Data Retention, Deletion and Backups

Retention should be determined by data category, not by a single indefinite period. Local conversation history can remain on the user’s device until the user deletes it, clears the application data, or removes the storage location. Local models remain until deleted. Temporary files should be removed when the operation finishes or according to a short cleanup cycle. Diagnostic logs should use size or time limits so they do not grow indefinitely.

Publisher-operated support records may be retained long enough to resolve the issue, document the resolution, prevent repeated abuse, and meet legal requirements. Safety reports about harmful AI output may be retained for a defined period sufficient to investigate patterns and respond to Microsoft Store obligations. When a report contains unnecessary personal information, the publisher should minimize or redact that information where practical.

Deletion from the application does not necessarily delete copies created outside the application. A user may have exported a chat, saved a generated document, copied text to the clipboard, synchronized a folder with cloud backup, or created a system image. Windows, antivirus software, backup products, and third-party sync services operate independently. OpenMindAI can only delete data it controls and can identify.

Where remote user-account data exists, a privacy request should identify the account or service and the data to be deleted. Some information may be retained after a deletion request where legally permitted or required, for example to prevent fraud, comply with tax or security obligations, establish legal claims, or maintain a minimal suppression record so an opt-out remains effective. Such exceptions should be narrow and documented.

Security Safeguards

OpenMindAI uses a defense-in-depth approach appropriate to desktop and mobile applications. Relevant safeguards include signed or integrity-checked distributions where available, authenticated HTTPS downloads, restricted application permissions, local data isolation, safe update design, dependency review, secret redaction in logs, secure credential storage, clear trust boundaries for imported models, and testing on supported desktop and mobile operating systems. Security controls should be proportionate to the sensitivity of the data the application actually processes.

No software can guarantee absolute security. A local-first design reduces some remote exposure but does not protect against a compromised operating system, malicious browser extension, malware, stolen device, weak Windows password, insecure remote desktop configuration, or another local administrator. Users are responsible for maintaining operating-system updates, endpoint protection, strong credentials, and appropriate device encryption. Enterprise users should evaluate OpenMindAI against their own security policies before processing confidential information.

OpenMindAI should avoid requesting administrator privileges for ordinary use when they are unnecessary. Installation may require elevation depending on the installer scope, but the running application should follow least-privilege principles. Updates should not execute arbitrary remote code outside the documented update channel. Downloaded model files should be treated as data, while executable runtimes should come from controlled, verified sources.

Vulnerability reports should be handled through a documented security contact or repository security mechanism. Reports should include affected version, reproduction steps, impact, and any relevant logs without unnecessary personal data. The publisher should acknowledge credible reports, investigate proportionately, issue fixes when appropriate, and avoid retaliating against good-faith security research that complies with applicable law and responsible disclosure practices.

User Controls and Privacy Rights

OpenMindAI should provide practical controls inside the application rather than relying entirely on legal text. Relevant controls include deleting a conversation, clearing all local chat history, removing downloaded models, choosing the storage location, disabling optional online features, disconnecting integrations, managing microphone or camera permissions through Windows, exporting user-created content, opening the local data folder, and reviewing the privacy policy from Settings or About.

Depending on jurisdiction and whether the publisher actually holds personal information about the user, privacy laws may provide rights to be informed, obtain access, correct inaccurate data, request deletion, restrict certain processing, receive portable data, object to processing, withdraw consent, opt out of sale or sharing, and complain to a supervisory authority. These rights generally apply to data controlled by the publisher; they do not require the publisher to retrieve local data that never left the user’s device and that the publisher cannot access.

A user making a privacy request should identify the relevant OpenMindAI service, the approximate date of interaction, and enough information to locate the record without sending unnecessary sensitive data. The publisher may need to verify identity before disclosing or deleting remote account data. Verification should be proportionate: a request concerning a low-risk support ticket should not trigger collection of a government ID unless legally necessary.

The publisher should not discriminate against users for exercising applicable privacy rights. Some features may become unavailable when the requested deletion or opt-out makes the feature impossible to provide, but unrelated local functionality should remain available where technically practical. Requests should be answered within the time required by applicable law, with extensions or exceptions explained when permitted.

Region-Specific Privacy Disclosures

European Economic Area and European Union

Where the GDPR applies, personal-data processing should follow lawfulness, fairness, transparency, purpose limitation, data minimization, accuracy, storage limitation, integrity/confidentiality, and accountability. Individuals may have rights including access, rectification, erasure, restriction, portability, objection, and protections related to certain automated decision-making. The applicable controller, lawful basis, retention period, recipients, international-transfer mechanism, and complaint route should be identifiable for each remote service. Purely local processing that the publisher cannot access is materially different from publisher-controlled cloud processing and should be described accordingly.

United Kingdom

Where UK data-protection law applies, users may have rights broadly including information about processing, access, rectification, erasure in certain circumstances, restriction, portability, objection, and safeguards relating to automated decision-making. The UK regulatory framework has continued to evolve, including changes associated with the Data (Use and Access) Act. The publisher should review current Information Commissioner’s Office guidance when a release materially changes data practices or introduces significant remote processing.

California and Other U.S. State Privacy Laws

California residents may have rights under the California Consumer Privacy Act, as amended, including rights to know categories and specific pieces of personal information in applicable circumstances, request deletion subject to exceptions, correct inaccurate information, opt out of sale or sharing, limit certain uses of sensitive personal information, and receive non-discriminatory treatment for exercising rights. OpenMindAI’s intended local-first model does not require sale of personal information. If future monetization or advertising practices change that position, the policy and required opt-out mechanisms must be updated before the new practice begins.

Other Jurisdictions

Other countries and U.S. states may provide additional privacy rights or impose localization, consent, breach-notification, age-assurance, or cross-border transfer requirements. This document is not intended to override mandatory local law. If OpenMindAI establishes a targeted service in a jurisdiction with specific requirements, the publisher should add a localized privacy notice or supplemental terms rather than relying on a generic global statement.

Children and Age-Appropriate Use

OpenMindAI is a general-purpose desktop productivity and AI tool and is not intentionally designed as a service directed to children under 13. The publisher should not knowingly operate a remote service that collects personal information online from a child under 13 without satisfying applicable parental-notice and verifiable-consent requirements. In the United States, COPPA imposes specific obligations on operators of child-directed online services and on services with actual knowledge that they collect personal information online from children under 13.

Because local software can be installed on shared family computers, phones, or tablets, a child may use the application without the publisher ever receiving the child’s information. Parents and guardians remain responsible for supervising local use, controlling internet access, managing downloaded models, and deciding whether a child should use generative AI. If the application adds accounts, community features, cloud synchronization, remote AI profiles, or public sharing, age-related obligations should be reassessed before launch.

OpenMindAI should avoid marketing adult themes to children and should use age ratings accurately in Microsoft Partner Center. Where live generative AI can produce content beyond the maturity level expected for the Store listing, safety controls and clear user reporting mechanisms are important. Local models may differ in built-in safety behavior, so model selection should not be treated as a complete content-safety control.

Automated Processing and High-Impact Decisions

OpenMindAI generates content automatically, but ordinary text generation is not necessarily a legally significant automated decision about a person. The application is not intended to make final decisions on employment, credit, insurance, housing, education admissions, law enforcement, medical diagnosis, legal rights, or other high-impact matters without qualified human review. Users must not treat general-purpose model output as a substitute for the procedures, professional judgment, evidence, consent, or appeal rights required in regulated decision-making.

If a future OpenMindAI feature profiles individuals, ranks candidates, predicts sensitive traits, or makes decisions that produce legal or similarly significant effects, that feature requires a separate risk assessment, lawful basis, transparency notice, data-quality review, security controls, human-oversight design, and jurisdiction-specific compliance analysis. The existence of a general disclaimer is not enough for a high-risk automated decision system.

Users should not ask OpenMindAI to infer highly sensitive characteristics about identifiable individuals where doing so would be unlawful, discriminatory, invasive, or unsupported by reliable evidence. Generated statements about a real person should be verified before sharing. The publisher may introduce safety filters, warning labels, or restrictions for features that create elevated privacy or harm risks.

Security Incidents and Policy Changes

A security incident can include unauthorized access to a publisher-operated service, compromise of signing or update infrastructure, exposure of support data, leaked credentials, or malicious modification of a distributed binary. A problem confined to a user’s own compromised computer may not constitute a breach by the publisher, but the publisher should still provide remediation guidance when the application could help reduce harm.

When applicable law requires notification of a personal-data breach, the publisher should assess scope, categories of data, affected users, likely risk, containment steps, and regulatory obligations. Notifications should be clear and should not minimize known risk. Technical details may be withheld where disclosure would create additional security risk, but users should receive enough information to take protective action.

This Privacy Policy may change as OpenMindAI adds features, changes vendors, modifies its storage architecture, or responds to legal requirements. Material changes should receive a new effective date. Where a change creates a new use of personal information that requires consent or additional notice, the application should provide that notice before the changed processing begins. Merely posting a new policy should not be used to retroactively justify unrelated use of previously collected data when law requires more.

Contact and Complaints

Privacy, security, support, or content-safety questions may be submitted through the official OpenMindAI contact page at https://openmindai.vercel.app/contact. The main OpenMindAI website is https://openmindai.vercel.app/. These URLs should remain reachable from the desktop and mobile applications, relevant store listings, and published policy pages so users have a consistent way to contact the publisher.

Users in jurisdictions that provide a right to complain to a privacy regulator may contact the competent supervisory authority. Users should not be required to waive that right as a condition of using the software. The publisher welcomes an opportunity to address a concern directly, but contacting the publisher does not remove any statutory complaint right.

Terms of Use and End User License Agreement

These Terms govern use of the OpenMindAI Desktop and Mobile Applications. They are written to be compatible with a locally installed AI application distributed through the Microsoft Store or directly by the publisher. Store-specific consumer rights and mandatory local law take priority where they cannot legally be waived.

Acceptance and Eligibility

By installing, launching, or using OpenMindAI, the user agrees to these Terms to the extent permitted by law. If the user does not agree, the user should not use the application and may uninstall it. An organization that deploys OpenMindAI for employees is responsible for ensuring that its internal use, data handling, model selection, and connected services comply with its contracts, policies, and applicable law.

Users must have legal capacity to enter into these Terms or use the software under the supervision and authorization of a parent, guardian, employer, or other responsible party where required. OpenMindAI does not grant a user permission to access data, systems, websites, devices, models, or services that the user is not otherwise authorized to access.

Software License and Permitted Use

Subject to these Terms and any license notice included with a specific release, the publisher grants the user a limited, non-exclusive, non-transferable except as permitted by law, revocable license to install and use the OpenMindAI application for lawful personal, educational, research, development, or business purposes. This license covers the OpenMindAI application code distributed under the publisher’s terms; it does not override the separate licenses of third-party models, libraries, runtimes, fonts, icons, codecs, or other components.

Users may configure supported local models, choose storage locations, create prompts and outputs, and integrate permitted third-party services. Users may not misrepresent themselves as the publisher, remove legally required notices, bypass licensing or security mechanisms, distribute malware under the OpenMindAI name, or use the application in a way that infringes third-party rights. Reverse engineering rights provided by mandatory law or an applicable open-source license are not restricted by these Terms.

Acceptable Use Policy

OpenMindAI is a general-purpose tool, but users remain responsible for how they use it. The software must not be used to facilitate unlawful access to computer systems, theft of credentials, deployment of malware, stalking, non-consensual surveillance, sexual exploitation, abuse of children, credible threats, targeted harassment, fraud, deceptive impersonation, illegal weapons activity, or other unlawful conduct. Security research and defensive cybersecurity work are legitimate when performed with authorization and appropriate safeguards.

Users must respect intellectual-property rights, privacy rights, confidentiality duties, contractual restrictions, and laws governing the data they provide to the application. A user who imports a document represents that the user has a lawful basis to process it. OpenMindAI does not grant rights to copyrighted books, proprietary source code, customer databases, confidential research, or other material merely because a model can process the material.

Users must not intentionally present AI-generated text, images, audio, or code as authentic human-origin content where doing so would deceive others in a harmful or unlawful manner. Synthetic media involving real people should be handled with particular care. Users are responsible for disclosures required by law, platform rules, academic policies, employment rules, or professional standards.

Responsible AI and Content Safety

OpenMindAI contains or can host generative AI functionality. Microsoft Store policy requires products with live generative AI content to disclose that use, declare it in Partner Center, ensure generated dynamic content complies with applicable Store policies, and provide a way for users to report inappropriate generated content to the developer. The released application should therefore include a visible “Report AI content” or equivalent function, or a clearly accessible reporting path from the response interface or Help menu.

Safety behavior varies across model families and versions. A local model may not include the same filters as a hosted service. OpenMindAI may provide system prompts, warnings, model metadata, safety layers, or feature restrictions, but no control can guarantee that a generative model will never produce offensive, unsafe, misleading, biased, or illegal content. Users should report harmful outputs so the publisher can evaluate whether the issue is caused by the application, a model configuration, or user-supplied content.

The publisher may remove a model from the recommended catalog, block a compromised download, update default safety instructions, or restrict a network feature when needed to address security, legal, or Store compliance concerns. Removing a model from the recommended catalog does not necessarily delete a user’s manually stored copy, but the application may warn that the model is no longer supported or verified.

OpenMindAI should not market itself as affiliated with OpenAI, Google, Meta, Alibaba, NVIDIA, Microsoft, or any other model provider merely because it can run or integrate a model associated with that organization. Model family names may be used only in a factually accurate and legally permissible way. The product name, icon, screenshots, and description should make the independent publisher relationship clear.

AI Limitations, Accuracy and Professional-Use Warnings

Generative AI does not “know” facts in the same way a verified database does. Models generate outputs based on learned statistical patterns and the context supplied at inference time. Outputs may contain fabricated citations, nonexistent software functions, insecure code, mathematical mistakes, outdated information, biased assumptions, or confident statements that are false. A longer answer is not necessarily a more accurate answer.

OpenMindAI is not a licensed medical, legal, financial, tax, accounting, engineering-safety, emergency, or mental-health professional. The application may assist with drafting, explanation, brainstorming, or analysis, but users must obtain qualified professional advice for decisions where errors can materially affect health, legal rights, finances, safety, or public welfare. Users should not delay emergency services or professional care because of AI output.

Code generated by an AI model should be reviewed, tested, scanned, and secured before production use. Users should check licensing implications, dependency versions, authentication and authorization logic, input validation, cryptography, error handling, resource limits, data deletion, and supply-chain risk. OpenMindAI makes no promise that generated code is secure or compatible with a particular project.

Research and academic users must follow institutional rules on AI assistance, authorship, citation, plagiarism, reproducibility, and disclosure. A model can invent references or misstate a paper. Users remain responsible for checking sources and should not cite an AI-generated reference unless the underlying publication has been independently verified.

User Content and Intellectual Property

As between the user and OpenMindAI, the user retains the rights the user already has in prompts, files, and other content provided to the application. The publisher does not claim ownership of user content merely because it is processed locally. The user grants only the limited rights reasonably necessary for a selected remote feature to process content when the user chooses that feature, subject to the applicable provider terms.

Rights in generated output can depend on jurisdiction, model license, source material, and the nature of the output. The publisher does not guarantee that every generated output is protectable by copyright, unique, non-infringing, or free of third-party rights. Similar or identical output may be generated for different users. Users are responsible for reviewing output before commercial publication or incorporation into proprietary products.

OpenMindAI branding, original application graphics, documentation, and publisher-authored code remain protected by applicable intellectual-property law and any stated software license. Third-party trademarks remain the property of their respective owners. Reference to a model or company does not imply endorsement unless expressly stated.

Third-Party Models, Software and Licenses

OpenMindAI depends on open-source and third-party components. Each component can have its own license, notice, attribution, patent terms, warranty disclaimer, and redistribution conditions. The application should provide an “Open Source Notices” or “Third-Party Licenses” section and keep it synchronized with each release. A bundled component’s license controls that component where it conflicts with a general statement in these Terms.

Model licenses deserve separate attention because model weights are not always governed like ordinary open-source software. A model may permit local use but impose restrictions on redistribution, fine-tuning, commercial use, generated-content use, or prohibited activities. OpenMindAI should not label a model “free” solely because it can be downloaded without payment. The catalog should distinguish price from license rights and should link to the authoritative license where feasible.

Third-party services may change, rate-limit, suspend, charge for, or discontinue their APIs. OpenMindAI is not responsible for a third party’s independent service availability, pricing, privacy policy, or model behavior. If the user supplies an API key, the user is responsible for charges and account terms associated with that key.

Updates, Availability, Support and Lifecycle

OpenMindAI may receive security fixes, feature updates, model-catalog changes, runtime updates, or compatibility improvements. Distribution through the Microsoft Store may use Store-managed mechanisms depending on the package type, while direct distributions may use a publisher-operated update mechanism. The app should clearly identify the installed version and should not replace itself through an undocumented channel.

Updates can change system requirements or deprecate models whose licenses, security status, or technical compatibility have changed. The publisher should provide release notes for material changes and should preserve a reasonable path to export or retain user-created content. No commitment is made that every historical model will remain supported indefinitely.

Support is provided on a reasonable-efforts basis through channels published by the publisher. The publisher may request logs or reproduction steps but should not require users to disclose unrelated private content. Unsupported operating systems, modified binaries, maliciously altered runtimes, or unverified models may limit the publisher’s ability to reproduce a problem.

Warranty Disclaimer, Liability and Termination

To the maximum extent permitted by applicable law, OpenMindAI is provided on an “as is” and “as available” basis without a guarantee that AI output will be accurate, complete, non-infringing, safe, uninterrupted, or suitable for a particular purpose. Some jurisdictions do not allow exclusion of certain implied warranties, so those exclusions apply only to the extent legally permitted. Mandatory consumer guarantees remain unaffected.

To the maximum extent permitted by law, the publisher is not liable for indirect, incidental, special, consequential, exemplary, or punitive damages arising from use of AI-generated output, loss of local data, user-configured third-party services, unsupported models, or reliance on inaccurate content. Any legally enforceable limitation should be interpreted subject to mandatory consumer protection, product liability, privacy, and other non-waivable law. Nothing in these Terms excludes liability that cannot lawfully be excluded.

The user may stop using the application at any time by uninstalling it and deleting associated data. The publisher may discontinue a remote service or terminate access to publisher-operated online features for abuse, security risk, legal requirements, or material breach of these Terms. Local software already installed may continue to function to the extent technically possible, but discontinued online endpoints or catalogs may not remain available.

EULA and Microsoft Store and Platform-Specific Terms

When OpenMindAI is acquired through the Microsoft Store, the transaction and distribution are also subject to applicable Microsoft Store terms. Microsoft is not the publisher of OpenMindAI unless explicitly stated otherwise. The publisher remains responsible for the application’s functionality, support, privacy disclosures, and content compliance. These Terms do not grant the user rights in Microsoft software or services beyond the terms that Microsoft separately provides.

The Store listing should accurately state essential dependencies, supported architecture, system requirements, AI functionality, privacy policy URL, support contact, and any material limitations. Store screenshots must represent the actual product experience. If the application offers live generative AI, that functionality must be disclosed in metadata and declared during the submission process. The application should provide a mechanism for reporting inappropriate AI-generated content and the publisher should maintain a process to act on reports.

If the Microsoft Store or mandatory law grants the user additional refund, cancellation, repair, replacement, or consumer rights, those rights are not reduced by this EULA. If a conflict exists between these Terms and non-waivable law, the law controls to the extent of the conflict.

Security, Governance and Store Compliance

Privacy and Security Governance Standard

The public Privacy Policy should be backed by operational practices. OpenMindAI releases should maintain a lightweight data-protection inventory covering every network endpoint, permission, local storage location, third-party SDK, model source, update channel, analytics event, support workflow, and data-export or deletion function. A feature should not be added to production merely because the code works; the release owner should also confirm how the feature changes data flow and whether the privacy notice, consent, Store declaration, or security model must change.

A privacy review should answer five questions for every new feature: what data is used; where the data originates; where it is processed and stored; who can receive it; and how the user can control or delete it. A security review should additionally consider trust boundaries, authentication, authorization, secret handling, executable downloads, path traversal, injection, model-supply-chain risk, remote content, logging, updates, and rollback behavior.

Production secrets such as code-signing credentials, API keys, repository tokens, and service credentials must not be embedded in the public source tree or shipped as reusable plaintext secrets. User-supplied API keys should be protected using available operating-system credential facilities or equivalent secure storage. Build pipelines should use protected secrets, signed releases where practical, and reproducible version metadata so a published binary can be traced to a source revision and release record.

The publisher should maintain a dependency-update process and review security advisories for Tauri, Rust crates, Node/JavaScript dependencies, WebView components, inference runtimes, model loaders, archive libraries, and installer tooling. Dependency updates should be tested for privacy regressions as well as crashes. A telemetry SDK, for example, can materially change privacy behavior even if the user interface is unchanged.

Microsoft Store Compliance

The following matrix is a practical implementation checklist derived from current Microsoft Store expectations. It is not a replacement for reviewing the latest Store Policies at the time of submission.

• Area: Accurate representation

  • OpenMindAI requirement: Store name, description, screenshots, features and limitations must match the actual build.
  • Implementation evidence: Store listing review against release candidate.
  • Release status: Required

• Area: Privacy policy

  • OpenMindAI requirement: Stable HTTPS privacy-policy URL; describe personal information accessed, collected, transmitted, used, stored, secured, disclosed and user controls.
  • Implementation evidence: Hosted policy + in-app link.
  • Release status: Required for Win32/personal information

• Area: Generative AI disclosure

  • OpenMindAI requirement: Disclose live generative AI in Store metadata and Partner Center.
  • Implementation evidence: Submission declaration + first-run/About disclosure.
  • Release status: Required

• Area: AI reporting

  • OpenMindAI requirement: Users need a way to report inappropriate AI-generated content.
  • Implementation evidence: Report action or visible support/report workflow.
  • Release status: Required

• Area: Security

  • OpenMindAI requirement: No malware, deceptive downloads or unsafe remote execution; use trusted distribution/update paths.
  • Implementation evidence: Signed/integrity-checked release and security test record.
  • Release status: Required

• Area: Third-party IP

  • OpenMindAI requirement: Names, logos, models and content must be used under license or applicable law.
  • Implementation evidence: Third-party notices + model license catalog.
  • Release status: Required

• Area: Permissions

  • OpenMindAI requirement: Request only capabilities needed for actual functionality.
  • Implementation evidence: Permission inventory and runtime prompts.
  • Release status: Required

• Area: Age rating

  • OpenMindAI requirement: Complete age-rating questionnaire accurately.
  • Implementation evidence: Partner Center rating record.
  • Release status: Required

• Area: Installer metadata

  • OpenMindAI requirement: ProductName, Publisher, Version, language and uninstall information should be correct.
  • Implementation evidence: Clean VM install/uninstall test.
  • Release status: Required

• Area: Testability

  • OpenMindAI requirement: Certification reviewers can install and exercise core features.
  • Implementation evidence: Certification notes with setup/model instructions.
  • Release status: Required

• Area: Support

  • OpenMindAI requirement: Provide working support route and policy links.
  • Implementation evidence: Store listing support URL/contact.
  • Release status: Required

• Area: Updates

  • OpenMindAI requirement: New versions must use documented release/update mechanism and must not silently alter listed behavior.
  • Implementation evidence: Versioned release artifacts + notes.
  • Release status: Required

Mobile App Store Compliance

Mobile releases should be reviewed against the requirements of each distribution platform used for the published build. The exact store forms and labels can change, so OpenMindAI should keep the public policy, in-app behavior, permissions, screenshots, AI disclosures, and store metadata synchronized with the released application.

• Privacy and data-safety disclosures should describe the data categories actually collected, transmitted, shared, retained, or processed by the mobile build.

• Sensitive permissions should be requested only for features that need them, and the purpose shown to the user should match the real use of the permission.

• Local AI features and online AI features should be clearly distinguished so a mobile store reviewer and an end user can understand when content stays on the device and when content is sent to a remote service.

• AI-generated content, model limitations, user reporting, and safety controls should be described consistently in the app and store listing where the distribution platform requires such disclosures.

• Screenshots, feature descriptions, privacy statements, and age-related information should reflect the current mobile build rather than planned or removed functionality.

• Mobile releases should be tested for install, update, first launch, permission denial, permission revocation, local data deletion, account or integration disconnect, offline behavior where supported, background restrictions, and uninstall behavior.

Release and Certification Checklist

• Build the exact release candidate from a tagged or otherwise traceable source revision and record the release build identifier.

• For desktop releases, install on a clean supported Windows environment and verify first launch, normal launch, model discovery or download, local inference, document features, settings, and uninstall.

• For mobile releases, test on supported phones or tablets and verify first launch, permission prompts, model discovery or download where supported, local inference where supported, online features, settings, data deletion, and uninstall.

• Confirm that any claim such as “offline,” “local,” “private,” or “no data sent” is scoped to the specific feature for which it is true.

• Capture network traffic during local-only mode and verify that prompts and files are not unexpectedly transmitted.

• Test every optional network feature and document destination domains, request payload categories, authentication, and user-facing notice.

• Confirm privacy policy and Terms URLs use HTTPS, are reachable without account login, and match the released product behavior.

• Add an in-app link to Privacy Policy, Terms, Open Source Notices, build information, support, and AI-content reporting.

• Declare generative AI use in Partner Center and ensure the Store description clearly explains the AI functionality before acquisition.

• Verify that Microsoft Store screenshots and feature claims reflect current UI and do not use third-party logos or trademarks misleadingly.

• Ensure model names are presented as third-party model families where applicable and not as claims that OpenMindAI owns those brands.

• Run malware/antivirus checks and verify runtime/model downloads come from controlled HTTPS sources with integrity verification where available.

• Test silent installation/uninstallation parameters if using the Win32 MSI/EXE Store path and verify correct Add/Remove Programs metadata.

• Confirm no required dependency is silently downloaded in a manner that violates the Store distribution path or misleads the user.

• Complete age rating accurately and review whether unrestricted model output affects content maturity or requires additional controls.

• Provide certification notes explaining local model download size, expected first-run behavior, offline mode, test model, and any hardware requirements.

• Review desktop and mobile permissions for microphone, camera, file access, notifications, or other sensitive capabilities and ensure each is feature-justified.

• For mobile releases, verify the permission declarations and privacy disclosures required by the target app store, and confirm that the declarations match the exact mobile build.

• Test mobile install, first launch, permission prompts, local model behavior where supported, online features, notifications, background restrictions, data deletion, logout or integration disconnect, and uninstall behavior on supported devices.

• Test deletion: conversation delete, clear history, model delete, cache cleanup, integration disconnect, and uninstall data behavior.

• Review logs for secrets and prompt leakage; ensure support bundles do not automatically include private user content.

• Verify update signatures/integrity, rollback behavior where relevant, and that a failed update does not corrupt user history or models.

• Archive release artifacts, checksum values, third-party notices, policy version, Store listing text, and certification notes for future audit.

Data Inventory, Retention and Permission Details

Data inventory

• Data category: Prompts/chats

  • Typical source: User input
  • Default location: Local database
  • Remote transmission: No for local model; yes if user selects remote feature
  • Primary purpose: Inference and history
  • User control: Delete chat / clear history

• Data category: Generated outputs

  • Typical source: AI model
  • Default location: Local database/exported file
  • Remote transmission: Only when user shares or remote workflow requires
  • Primary purpose: User-requested content
  • User control: Delete/export

• Data category: Files/documents

  • Typical source: User-selected file
  • Default location: Original path + temporary working data
  • Remote transmission: Only for selected remote processing
  • Primary purpose: Analysis/generation
  • User control: Close/delete source; clear temp

• Data category: Models

  • Typical source: Official or third-party repository
  • Default location: User-selected/model directory
  • Remote transmission: Download request to host
  • Primary purpose: Local inference
  • User control: Delete model

• Data category: Settings

  • Typical source: User/application
  • Default location: Local config
  • Remote transmission: Normally no
  • Primary purpose: Preferences and runtime setup
  • User control: Reset settings

• Data category: Device capability

  • Typical source: Operating system
  • Default location: Memory/local config/log
  • Remote transmission: Only for support/remote diagnostics if implemented
  • Primary purpose: Compatibility
  • User control: Disable diagnostic sharing

• Data category: Logs

  • Typical source: Application/runtime
  • Default location: Local logs directory
  • Remote transmission: Only if user sends/support feature enabled
  • Primary purpose: Troubleshooting/security
  • User control: Delete logs

• Data category: API credentials

  • Typical source: User/integration
  • Default location: Protected local credential storage where supported
  • Remote transmission: To selected provider
  • Primary purpose: Authenticated integration
  • User control: Disconnect/delete credential

• Data category: Safety report

  • Typical source: User
  • Default location: Publisher support system
  • Remote transmission: Yes, user-initiated
  • Primary purpose: Investigate harmful output
  • User control: Request deletion subject to legal needs

Recommended retention schedule

• Record: Local chats

  • Recommended default: Until user deletes or clears app data
  • Reason: User-controlled continuity
  • Deletion trigger: User deletion/uninstall cleanup setting

• Record: Models

  • Recommended default: Until user removes them
  • Reason: Large reusable local asset
  • Deletion trigger: User model deletion

• Record: Temporary processing files

  • Recommended default: As short as technically practical
  • Reason: Complete requested task
  • Deletion trigger: Task completion/cleanup

• Record: Local diagnostic logs

  • Recommended default: Rolling limit, e.g. 14–30 days or size cap
  • Reason: Troubleshooting without indefinite accumulation
  • Deletion trigger: Automatic rotation/user clear

• Record: Support tickets

  • Recommended default: Typically 12–24 months unless law/business need differs
  • Reason: Issue history and abuse prevention
  • Deletion trigger: Retention expiry/request where applicable

• Record: Safety reports

  • Recommended default: Typically 12–24 months, minimized
  • Reason: Pattern analysis and Store obligations
  • Deletion trigger: Retention expiry/request where applicable

• Record: Update/download server logs

  • Recommended default: Short security/operations period
  • Reason: Abuse detection and reliability
  • Deletion trigger: Scheduled log expiration

The values above are recommended defaults, not claims about a deployed server. Before publication, replace them with the actual retention periods used by production services. If OpenMindAI operates no remote support or analytics database, state that clearly rather than inventing one.

Sensitive permission matrix

• Permission/capability: Microphone

  • Use case: Voice prompt or transcription
  • Privacy requirement: User-initiated capture; disclose local vs remote processing
  • Default approach: Request on first use, not at startup

• Permission/capability: Camera

  • Use case: Image capture/vision feature if implemented
  • Privacy requirement: User-initiated capture; no background recording
  • Default approach: Request on first use

• Permission/capability: File access

  • Use case: Open/import/export user files
  • Privacy requirement: Use picker or explicit directories; avoid whole-drive crawl
  • Default approach: User selection

• Permission/capability: Network

  • Use case: Models, updates, search, integrations
  • Privacy requirement: Separate offline inference from remote requests
  • Default approach: Allowed only for documented features

• Permission/capability: Notifications

  • Use case: Download/update/task completion
  • Privacy requirement: Avoid sensitive prompt text on shared lock screens
  • Default approach: Optional and configurable

• Permission/capability: Clipboard

  • Use case: Paste/copy content
  • Privacy requirement: Do not monitor background clipboard unnecessarily
  • Default approach: Explicit paste/copy action

• Permission/capability: GPU/Hardware info

  • Use case: Model compatibility/performance
  • Privacy requirement: Keep local unless support diagnostics are shared
  • Default approach: Local detection

User-Facing Short Privacy Notice

The following short notice can be adapted for the application’s first-run privacy panel or Settings page. It should appear together with links to the full Privacy Policy and Terms.

OpenMindAI Privacy at a Glance

• OpenMindAI is designed for local AI processing. When you use a local model, your prompt and generated response are processed on your computer and do not need to be sent to an OpenMindAI inference server. Chat history and downloaded models may be stored locally so you can reuse them. You can delete local chats and models through the application.
• Optional online features are different. Model downloads, update checks, web search, connected accounts, remote AI providers, or support reports may send the information needed for that feature over the internet to OpenMindAI or the third-party service you selected. The app should show when an online feature is being used.
• Do not put passwords, private keys, or highly sensitive information into AI prompts unless you understand the storage and network settings you are using. AI responses can be inaccurate or unsafe. Review important information before relying on it.
• OpenMindAI uses generative AI. You can report inappropriate or harmful AI-generated content through the application support/reporting channel. Read the full Privacy Policy and Terms for details.

Privacy request workflow

• Receive the request through the official privacy/support channel and record the receipt date.

• Determine whether the requested data is actually controlled by the publisher or exists only on the user’s local device.

• Identify the jurisdiction and applicable response deadline without collecting unnecessary location information.

• Verify identity proportionately where disclosure or deletion of remote personal data creates risk.

• Locate responsive records across support, account, safety-report, analytics, or other production systems actually in use.

• Apply lawful exceptions narrowly and document the reason for any information withheld or retained.

• Complete access, correction, deletion, restriction, portability, objection, opt-out, or consent withdrawal as applicable.

• Respond in clear language and record completion for accountability without retaining unnecessary copies of identity documents.

Security incident workflow

• Contain the affected system, credential, download, update, repository, or service without destroying relevant evidence.

• Determine whether user personal data, code-signing material, update integrity, or support information was affected.

• Revoke or rotate exposed credentials and block malicious artifacts or endpoints.

• Assess affected builds, time window, users, data categories, and likely harm.

• Engage qualified legal/security expertise where notification duties or significant risk may exist.

• Notify Microsoft or other distribution providers when their policies or incident channels require it.

• Provide affected users with actionable remediation steps when notification is appropriate or required.

• Publish fixed builds, update checksums/signatures, and preserve a post-incident record of root cause and corrective actions.

AI content report workflow

• Allow the user to report a specific response or safety concern without forcing public disclosure of the conversation.

• Collect the minimum context needed to reproduce or understand the issue and clearly indicate if conversation text will be attached.

• Classify the report: harmful content, illegal content, privacy issue, hallucination, security issue, model defect, or other.

• Determine whether the issue is application behavior, a specific model, a remote provider, or user-supplied content.

• Take proportionate action such as safety-rule update, model-catalog warning/removal, remote-provider escalation, bug fix, or user guidance.

• Retain the report only as long as reasonably necessary for investigation, pattern analysis, legal duties, and Microsoft Store compliance.

Source References and Maintenance Notes

The legal and Store-policy descriptions in this pack were grounded in official or regulator-maintained sources current as of 3 September 2026. Because policies and laws evolve, the publisher should review these sources before every major Store submission and at least annually for a maintained public policy.

• Microsoft Store Policies. Privacy policy requirements, accurate representation, security, intellectual property, age ratings and live generative AI content requirements. https://learn.microsoft.com/en-us/windows/apps/publish/store-policies

• Microsoft Learn — MSI/EXE app certification process. Certification guidance including installer information, privacy policy URL where required, accurate description and policy review. https://learn.microsoft.com/en-us/windows/apps/publish/publish-your-app/msi/app-certification-process

• European Commission — Principles of the GDPR. GDPR processing principles including transparency, purpose limitation, minimization, storage limitation, security and accountability. https://commission.europa.eu/law/law-topic/data-protection/information-business-and-organisations/principles-gdpr_en

• California Department of Justice — California Consumer Privacy Act. California consumer rights including know, delete, opt out of sale/sharing and non-discrimination. https://oag.ca.gov/privacy/ccpa

• U.S. Federal Trade Commission — Children’s Privacy / COPPA. COPPA overview and parental consent requirements for covered child-directed online services. https://www.ftc.gov/news-events/topics/protecting-consumer-privacy-security/kids-privacy-coppa

• UK Information Commissioner’s Office — Individual rights. UK data-protection rights and privacy notice guidance. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/

• UK Information Commissioner’s Office — Right to be informed. Transparency expectations for privacy information, including purpose, retention and sharing. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/individual-rights/right-to-be-informed/

Maintenance rule: if the application begins collecting analytics, creates user accounts, syncs chats to the cloud, processes payments, provides public sharing/community features, performs background screen/audio capture, enables remote agents to take actions on third-party services, uses advertising identifiers, or trains publisher-controlled models on user content, this document must be revised before that processing becomes active. Those changes materially alter the privacy and risk profile and should not be covered by vague language intended for the current local-first architecture.

Publication Checklist for This Document

• Host the Privacy Policy and Terms on stable HTTPS pages under a domain controlled by the publisher.

• Add a working privacy/support contact method; do not publish a placeholder address.

• Confirm the application’s actual telemetry behavior, online endpoints, retention periods, and integration providers against this text.

• If analytics are absent, state that clearly. If analytics are present, identify provider, event categories, purpose, retention, and opt-out control.

• Confirm how uninstall treats local history, models, settings, logs, and caches and align the deletion language with the installer.

• Add the Open Source Notices generated from the exact release dependency set.

• Add model-specific license links and attribution for every model offered in the recommended catalog.

• Ensure the Store listing links to the current public Privacy Policy and discloses generative AI.

• Ensure the app includes an AI-content reporting mechanism before Microsoft Store certification.

• Have qualified counsel review the final policy if OpenMindAI will process substantial cloud data, target children, operate paid subscriptions, handle regulated data, or be offered to enterprise customers under contractual data-processing obligations.