MiiA Account & Data Deletion Policy

MiiA is provided by:

NETCOMTESCO CO., LTD. 網通益購科技有限公司 Taiwan Unified Business Number: 53106072 Place of Establishment: Taiwan

Brand:

MiiA

For general account, data, and privacy assistance:

support@miia-ai.com

For information-security matters:

security@miia-ai.com

Users should not necessarily be required to delete their entire MiiA account merely to manage particular data.

Depending on formally released functionality, MiiA should provide appropriate controls for matters such as:

• deleting or revoking Personal Memory;
• deleting calendar events or reminders;
• managing devices;
• managing friends or Trust Relationships;
• managing group membership;
• deleting or managing messages and attachments;
• disabling particular functionality;
• revoking particular permissions.

Account Deletion means requesting termination of the MiiA account itself and processing account-related data according to the formally approved deletion contract.

When MiiA formally releases an App that supports account creation, users should be provided with an in-App mechanism to:

initiate account deletion.

The process should:

1. be reasonably discoverable;
2. clearly explain important consequences of account deletion;
3. apply appropriate identity verification for the high-risk deletion operation;
4. not use unnecessary or unreasonable procedures to obstruct a legitimate deletion request;
5. provide necessary confirmation before submission;
6. provide an understandable status or outcome after submission.

Users should not be required to purchase, subscribe to, or create another paid service merely to delete a MiiA account.

If a user:

• cannot sign in to the MiiA App;
• no longer has access to the original device;
• cannot use the normal in-App deletion flow because of a technical problem;
• otherwise reasonably requires assistance,

the user may use the account and data deletion channel made available through the official MiiA website.

After the public website is formally launched, miia-ai.com should provide a publicly discoverable Account & Data Deletion resource or request path.

Users may also request assistance through:

support@miia-ai.com

The ability to send email from a particular address does not automatically prove that the sender is the legitimate controller of a particular MiiA account.

To protect users against:

• malicious deletion;
• account takeover;
• impersonation;
• social engineering;
• third-party attempts to delete another person’s account,

MiiA may require identity verification proportionate to the risk.

MiiA will not require users to send the following through email:

• passwords;
• OTP codes;
• Passkey private keys;
• recovery secrets;
• full payment-card data.

If an account still holds important authority or is subject to an unresolved security state, necessary steps may need to be completed before deletion.

Examples may include:

• Trusted Group ownership;
• Admin or Owner roles;
• incomplete ownership transfer;
• Security Hold;
• identity disputes;
• account recovery;
• confirmed security incidents;
• legal or formal dispute holds.

These safeguards must not be used as a basis to obstruct a lawful deletion request indefinitely.

If a user holds Owner or other necessary authority within a Trusted Group, MiiA should follow its approved group ownership and exit rules.

Account deletion must not:

• unintentionally leave a group without a required Owner;
• permit AI to independently choose a new human Owner;
• allow the system to manufacture human authorization.

Where ownership transfer is required, it should follow the formally approved authority flow.

The effect of account deletion on group history, membership, role records, and content visible to other members must match actual Final RC and runtime behavior.

Depending on the account and released functionality, the account-deletion process may involve:

• basic account information;
• phone numbers and account identifiers;
• Trusted Device bindings;
• authentication and security states;
• Friend/Trust Relationship states;
• Trusted Group membership;
• Personal Memory;
• Calendar data;
• Reminders;
• Tasks;
• push tokens;
• messages and attachments;
• AI-related user context;
• Points and entitlement states;
• other data directly related to the account where no continuing lawful or necessary retention purpose exists.

Different categories of data may follow different deletion lifecycles depending on purpose and legal requirements.

Personal Memory should not be designed so that the user must delete the entire MiiA account merely to remove a saved Memory.

Depending on formally released functionality, users should be able to:

• view;
• correct;
• delete;
• revoke

Personal Memory.

Once Personal Memory has been deleted or revoked:

it should no longer be used as normal MiiA AI context.

When an account is deleted, Personal Memory should be processed through the applicable deletion process.

Users should be able to manage or delete formally supported:

• Calendar events;
• Reminders;
• Tasks;
• related personal context.

When an account is deleted, such data that remains linked to the account should enter the applicable deletion process unless a lawful or necessary retention reason applies.

When account deletion is completed, MiiA should, according to its formal Production architecture:

• revoke active device authority associated with the account;
• prevent the deleted account from obtaining new normal authenticated access;
• invalidate or remove push tokens that are no longer required.

An account that has been deleted should not retain normal account authority merely because an old device binding remains.

For Passkey/WebAuthn, MiiA processes account-side or credential-side data necessary to provide authentication.

MiiA does not obtain the user’s device-held Passkey private key.

After account deletion, the formal authentication architecture should:

• remove or revoke server-side authentication authority associated with the account where it is no longer required;
• prevent an old credential from continuing to function as normal authentication authority for the deleted account.

Actual Passkey and identity-provider revocation or deletion behavior must be proven through the Production implementation.

MiiA does not use an architecture in which it stores raw Face ID, fingerprint, or similar biometric templates.

Accordingly, normal MiiA account deletion should not make a misleading promise that MiiA will “delete stored Face ID templates” where MiiA did not possess such data in the first place.

Device-level biometric data is governed by the applicable operating system or trusted platform.

MiiA V1 follows the product principle:

Call media has 0-retention as a normal product capability.

MiiA therefore does not normally maintain a database of stored call recordings or videos for later playback that would need to be deleted when an account is removed.

Necessary:

• signaling;
• security;
• quality;
• session;
• incident

metadata is subject to the applicable retention and deletion matrix.

Deletion behavior for messages and attachments must distinguish between:

• data belonging to the user’s own account;
• data already sent to another user or group;
• copies lawfully held by recipients;
• security or audit metadata;
• server-side storage;
• backup copies.

Until runtime evidence is available, this Policy does not claim that deleting an account automatically causes all copies of every conversation to disappear from every other user’s history.

After account deletion, account-related data for which no continuing lawful retention purpose exists, including:

• private AI context;
• Personal Memory;
• user-specific AI state,

should stop being used for normal service purposes and enter the applicable deletion process.

Private data should not permanently escape user control merely because it was incorporated into a general AI training dataset after account deletion.

MiiA’s default policy is that private data is not a default source for general model training.

Deleting a MiiA App account does not necessarily mean that all:

• Support emails;
• Security incident correspondence;
• fraud-investigation records;
• dispute correspondence

are immediately deleted.

Such records may have purposes and lawful retention requirements distinct from the App account itself.

When the relevant purpose ends and no other lawful or necessary retention basis remains, such records should be handled under the applicable retention and deletion policy.

If an account has:

• Points;
• subscriptions;
• payment entitlements;
• transaction records,

account deletion may require separate treatment of these matters.

Product Entitlements

Normal account entitlements should terminate according to the applicable account-termination process.

Store Subscriptions

If subscriptions are later managed through Apple App Store, Google Play, or another approved Provider, deleting the MiiA account and cancelling a Store subscription may be separate actions.

If paid services are formally launched, MiiA must explain that distinction clearly.

Legally Required Transaction Records

Records that must be retained for:

• accounting;
• tax;
• transactions;
• refunds;
• disputes

may not be immediately deletable upon account deletion.

Such data should be retained only for the necessary purpose and period.

Some data may need to be retained after account deletion where necessary for:

• account-takeover investigation;
• abuse investigation;
• fraud prevention or investigation;
• security incidents;
• privileged-action auditing;
• disputes;
• legal obligations.

Such retention must:

• have a specific purpose;
• be proportionate to the risk;
• include only necessary data;
• last only as long as reasonably necessary.

A vague statement that data “may be useful for security” must not become justification for indefinite retention of all user data.

Where MiiA is legally required to preserve particular data, or the data is directly relevant to an ongoing lawful:

• dispute;
• investigation;
• security incident;
• legal hold,

that specific data may temporarily be excluded from ordinary deletion.

When the Legal Hold ends, the data should return to the normal retention and deletion process.

MiiA’s Owner policy is:

Deletion must be technically provable and must not consist merely of marking an account as “deleted.”

However, before Production evidence exists, the public Policy must not invent a fixed deletion SLA such as:

• 7 days;
• 30 days;
• 90 days.

Production backups may operate under a lifecycle different from active Production systems.

Accordingly, after an account is removed from active systems, some data may remain in encrypted backups until the normal backup rotation or purge cycle completes.

However:

• backups should not become normal active product data again;
• backup retention should not be indefinite;
• restore procedures should prevent previously deleted data from silently returning to normal active status.

Where data is processed by an approved Production Processor, account deletion may require or depend on the Provider’s applicable:

• deletion;
• expiry;
• purge;
• retention

process.

MiiA does not treat validation or candidate Providers as Production deletion authorities.

The final public version must be reconciled with the then-current:

Approved Processor Register

and actual Provider behavior.

After the formal account-deletion process is completed, the deleted account should generally no longer:

• sign in normally;
• retain its previous Trusted Device authority;
• receive normal push notifications;
• use its former Personal Memory;
• function as a normal active account.

Limited data retained for lawful security, dispute, accounting, or other necessary purposes does not mean that the account remains active.

Uninstalling the MiiA App from a device does not itself constitute an Account Deletion request.

If you wish to delete your MiiA account and applicable related data, you should use the formal:

• in-App Account Deletion flow;
• official website Account & Data Deletion resource;
• verified Support assistance process.

If MiiA later offers paid subscriptions:

deleting a MiiA account must not automatically be represented as cancelling every subscription managed by an external Store.

A subscription managed by Apple, Google, or another payment Provider may require cancellation through that Provider’s own mechanism.

Before paid MiiA services are formally launched, MiiA must not describe subscription-cancellation behavior that does not yet exist.

Treatment of unused Points after account deletion should follow formally published Points rules.

Until such rules exist, Points must not be represented as having nonexistent:

• cash value;
• refund rights;
• bank-balance status;
• investment value.

If MiiA later allows users to purchase Points, paid Points may require different product and legal governance from free or gifted Points.

In addition to deleting an entire account, a user may, depending on applicable law and released functionality, request deletion or cessation of processing of particular personal data.

MiiA should evaluate such requests according to:

• the category of data;
• the original purpose of collection;
• applicable user rights;
• legal obligations;
• legitimate security needs.

MiiA should not automatically reject a reasonable data-rights request solely because the user has not deleted the entire account.

Where MiiA has a specific lawful reason why a category of data cannot be immediately deleted, it should, where appropriate, reasonably explain:

• which category of data is affected;
• why temporary retention is required;
• the basis for retention;
• how the data will subsequently be handled.

A vague explanation such as “the system requires it” should not be used as the sole basis for refusing all deletion.

Account deletion must not be used to:

• destroy evidence of a serious security attack under investigation;
• evade legitimate transaction or consumer disputes;
• delete records that another person lawfully holds;
• violate the rights of third parties.

Any exception should apply only to the specific data reasonably necessary for that purpose.

It should not justify indefinite retention of the user’s entire account dataset.

If MiiA permits a user to create a new account after deletion:

• the new account should not automatically recover all deleted Personal Memory;
• old Trust Relationships should not automatically be restored merely because the old account previously existed;
• terminated high-authority states should not automatically return.

Actual re-registration behavior must be determined by the then-current Production identity architecture.

For general Account or Data Deletion assistance:

support@miia-ai.com

If your request concerns:

• account compromise;
• account takeover;
• a security vulnerability;
• another information-security incident,

please contact:

security@miia-ai.com

Do not send the following by email:

• passwords;
• OTP codes;
• recovery secrets;
• Passkey private keys;
• complete payment-card data;
• unnecessary medical or other sensitive information.

MiiA personnel should never ask you to provide a Passkey private key through email.

This Policy may be updated due to changes in:

• Account architecture;
• Data storage;
• Processors;
• App Store or Google Play requirements;
• Billing;
• legal requirements;
• Security architecture.

Each formal version should include:

• Version;
• Effective Date.

Material changes should receive appropriate notice according to applicable law and the nature of the change.