MULYAI Privacy Policy

Controlled beta legal document.

MULYAI PRIVACY POLICY — ENGLISH
Version: MULYAI-PRIVACY-v1.1-2026-09-25
Effective date: 25 September 2026
Controller: Gabriel Lagziel, Via Malaga 4, 20143 Milan, Italy
Contact: gabriellagziel@gmail.com
Telephone: +39 388 748 9687
1. SUMMARY
MULYAI is designed to be local-first. Your Work Memory stays on your device. MULYAI does not receive your sensitive work content by default.
The central MULYAI service does process limited personal data needed for registration/account operation, device/control-plane security, legal acceptance, support, product reliability/value telemetry, website delivery and security. This Policy explains what is processed, why, how long it is kept, who receives it and your rights.
2. SCOPE
This Policy applies to the MULYAI website, open worldwide beta registration/download flow, central Control Plane/backend, approved product telemetry, support/contact channels, Investor Wanted / Investor Access, authentication/service email, software/model artifact delivery and owner/admin systems. It also explains the boundary between central processing and local Work Memory on your computer.
It does not authorize external/cloud LLM processing of your work content in the current beta. Default AI reasoning is local. A future material change—such as cloud AI receiving work content, broader telemetry, advertising tracking or enterprise employee-monitoring use—requires an updated privacy/legal assessment before activation.
3. DATA CONTROLLER
Gabriel Lagziel
Via Malaga 4
20143 Milan, Italy
Email: gabriellagziel@gmail.com
Telephone: +39 388 748 9687
4. INFORMATION WE COLLECT CENTRALLY
A. Registration / customer profile
Required: full name, email, country, confirmation that you are at least 18, and legal acceptance.
Optional: phone, city, profession/field, employment status, company name.
Conditional: if you select “employed by a company”, whether you will use MULYAI for work connected to that employer.
We also create an internal Customer ID and account/status records needed to operate the beta.
B. Legal acceptance evidence
We keep minimum evidence of the legal state presented/accepted: internal customer reference, acceptance timestamp, accepted Beta Terms version, accepted Privacy version, accepted language/context and fact of acceptance/adult confirmation as necessary.
C. Customer/device and authorization data
The beta uses a product-generated Device/Install ID associated with a pseudonymous Customer ID, plus bounded device credential/public-key/fingerprint information and account/device authorization state. We do not use invasive hardware fingerprinting as the canonical identity model.
D. Privacy-safe product/value/health telemetry
MULYAI may send one locally aggregated cumulative snapshot per registered customer/device and local day. The approved schema is limited to app/build/version/channel; cumulative observation/runtime time; counts of Patterns and Skills; counts of proposed, qualifying and active Agents; run counts and independently Verified Result counts; verified Time Returned; permitted verified aggregate Value Returned where a documented calculation exists; and bounded product/device health fields and allowlisted health codes.
Telemetry is associated with a pseudonymous Customer ID + product-generated Device/Install ID so we can support the correct customer/device and measure product/value trends. Direct profile fields such as your name, email, phone or company are not included in the telemetry payload itself.
The telemetry schema prohibits free-form work content, arbitrary metadata and semantic descriptions of what you do.
E. Support/contact
The standard contact flow collects reply email + message. If diagnostics are needed, we request them separately so you can decide what to send. Diagnostics must not be automatically bundled with Work Memory. Please do not send passwords, private keys, credentials or unnecessary sensitive data.
F. Website / server / security data
When you use the website/backend, infrastructure providers may process ordinary technical information necessary to deliver and secure the service, such as IP address, timestamps, request/route metadata, browser/user-agent information and security/rate-limit events.
G. Admin/security evidence
Privileged-access and security audit records may contain admin identity, action/target references, timestamps and bounded security metadata. These logs must not contain your Work Memory/private work semantics.
H. Release/download/model-delivery data
We may process release version/channel, artifact identifiers/hashes/signature state, bounded download grants/tokens and update/release state necessary to supply and secure the beta. Shared software/model artifacts may be stored in Cloudflare R2. The current MULYAI R2 bucket is private and configured in Cloudflare’s Eastern Europe (EEUR) location.
I. Investor Wanted / Investor Access
If you request access to private investor materials, we may collect your name, email, optional company/fund, optional LinkedIn URL, optional note, email-verification status, access/revocation status, authentication/session information and bounded security/audit metadata. Investor access is separate from customer beta registration and is used to evaluate, provide and secure private investor access.
J. Authentication and service email
We process email-address and bounded delivery/authentication metadata needed to send confirmation, sign-in, security, download, necessary service/legal notices and user-initiated support. Current policy is service-only: registration emails are not used for newsletters, sales or promotional marketing.
5. DATA THAT STAYS LOCAL BY DEFAULT
MULYAI’s Work Memory and substantive observed-work context remain on your device by default. In the current Windows beta, Work Memory is encrypted locally with SQLCipher and the key material is protected for the current Windows user through Windows DPAPI.
Central MULYAI systems must not receive, through normal beta telemetry, Work Memory content; filenames/filesystem paths; document contents/extracted text; prompts or private messages; screenshots or image pixels; clipboard content; full keystroke/keylogging data; browser/URL history; account/application contents; Pattern/Skill/Agent names or task semantics; local execution authority; passwords, API keys or private keys.
MULYAI may process such information locally on your computer as part of the personal assistant function. Local processing remains relevant to privacy and is covered by product safeguards such as user control, local AI and local deletion/reset controls as actually implemented. The provider does not centrally receive it by default.
6. PURPOSES AND LEGAL BASES
Customer registration/account/download/service delivery: GDPR Art. 6(1)(b), steps/contract needed to provide the beta, plus Art. 6(1)(c) where a specific legal obligation applies.
Legal acceptance/version evidence: Art. 6(1)(f), legitimate interest in proving contractual/legal state and defending legal claims, and Art. 6(1)(c) where applicable.
Security, authentication, account/device authorization, abuse prevention and audit: Art. 6(1)(f) legitimate interests in protecting users/service and, where applicable, Art. 6(1)(c).
Product/value/health telemetry: Art. 6(1)(f), legitimate interests in reliability, support, product operation and verifying whether MULYAI returns value, balanced through local aggregation, one daily snapshot, a strict allowlist, no work semantics, bounded retention and an objection mechanism where Article 21 applies.
Optional profession/employment/company information: Art. 6(1)(f) for limited customer/product research and GTM understanding, subject to balancing and transparent optional collection. It is not required to supply MULYAI and is not used as blanket consent for marketing.
Support: Art. 6(1)(b) and/or Art. 6(1)(f), depending on the request.
Authentication/service email: Art. 6(1)(b), Art. 6(1)(f) and/or Art. 6(1)(c) as appropriate for account operation, security, necessary service/legal communications and support.
Investor access requests and private investor-room security: Art. 6(1)(f), legitimate interests in responding to investor access requests, managing investor relations and protecting non-public materials; Art. 6(1)(b) may also apply where processing is necessary for requested pre-contractual steps.
Direct marketing is not authorized by the Terms/Privacy acknowledgement. The current beta does not use registration emails for promotional marketing.
7. WHY TELEMETRY IS NOT WORK SURVEILLANCE
We need limited central data to know whether the product is running correctly, support a device/customer, understand longitudinal product/value performance and later substantiate approved Agent billing. Event-by-event work monitoring is not necessary for those purposes. Therefore the beta uses one daily locally aggregated snapshot and prohibits work semantics, filenames, content and free-form telemetry.
8. RECIPIENTS / PROCESSORS
Current known infrastructure includes:
- Supabase, Inc. — managed PostgreSQL, Storage, Auth and Edge Functions/control-plane backend. Verified MULYAI project primary region: eu-west-1 (Ireland).
- Vercel, Inc. — website hosting, global CDN/edge delivery/deployment and same-origin API rewrite/proxy layer.
- Cloudflare, Inc. — private R2 object storage/delivery for shared software/model artifacts. Current bucket mulyai-releases is configured in Cloudflare location Eastern Europe (EEUR); public access and the public development URL are disabled.
- Resend — transactional/authentication email service used for MULYAI service email.
- Amazon Web Services / Amazon SES — email-delivery infrastructure used by Resend for MULYAI transactional mail.
- Google/Gmail — if customer support/service correspondence is handled using the published Gmail address.
- GitHub — source-code/CI/deployment integration; it is not intended to receive customer Work Memory or ordinary application telemetry.
The current beta does not approve OpenAI, Anthropic, Google Gemini or another external LLM as a processor of your Work Memory/work content.
No crash/session-replay/advertising analytics provider is approved for the current beta. Stripe/payment processing is not active during the free beta.
9. INTERNATIONAL TRANSFERS
Supabase’s MULYAI primary project region is Ireland. Supabase is a US-based provider and may use authorized subprocessors/support outside the EEA subject to its applicable DPA/transfer safeguards.
Vercel operates globally distributed infrastructure and may process request data in the United States and other regions.
The current Cloudflare R2 bucket is configured in Cloudflare’s Eastern Europe (EEUR) location. Cloudflare may still use global corporate/support/subprocessor infrastructure subject to its applicable contractual and transfer safeguards.
Transactional/authentication email is sent through Resend and Amazon SES/AWS infrastructure and may involve processing outside the EEA subject to the applicable provider safeguards.
Where EEA personal data is transferred to a country without an adequacy decision, applicable DPAs, Standard Contractual Clauses or another lawful GDPR Chapter V safeguard must apply. We minimize the data transmitted through these providers and maintain a processor/transfer register as part of MULYAI’s compliance documentation.
10. RETENTION
We do not use one retention period for everything.
Ordinary customer profile: kept while needed for the account/beta relationship; after account closure/deletion, ordinary profile fields are deleted from the active backend within 30 days, unless a specific lawful legal/security basis requires longer.
Daily telemetry snapshots: rolling 12 months while attributable. After account closure/deletion, within 30 days we must irreversibly sever Customer ID and Device/Install ID linkage so any remaining history is genuinely anonymous and cannot be related back to the former customer/device. If irreversible anonymization cannot be technically demonstrated, affected telemetry is deleted within 30 days instead.
Legal acceptance/version evidence: minimum record only for the applicable legal claims/defense period. For Italy, the current operational rule is 10 years after account closure/deletion, unless applicable law requires a different period.
Investor access: incomplete/abandoned investor requests may be removed after up to 90 days of inactivity. Approved access data is retained while access is active. After revocation/closure, bounded request/access/security records may be retained for up to 12 months for security, audit and claims-defense purposes unless a specific legal hold or longer mandatory period applies.
Authentication/service email: account/authentication state is retained as needed for the account relationship and security. Delivery/provider logs follow the shortest documented operational/provider lifecycle reasonably necessary for security and delivery troubleshooting; MULYAI does not use them for marketing.
Support/contact: ordinary closed contact records removed no later than 90 days after closure unless a specific lawful legal/security hold applies; user-submitted diagnostics only as long as reasonably necessary for the support purpose.
Server/CDN operational/security logs: shortest practical period; MULYAI’s target is no more than 30 days for ordinary logs, with longer retention only for a concrete incident/legal need or unavoidable provider lifecycle that is documented.
R2 shared artifacts: shared software/model artifacts are not customer-profile records and may be retained while needed for supported release distribution. Bounded customer/download-grant metadata is subject to the applicable account/security retention rules. Current R2 object-level Data Access Logs are disabled.
Italian system-administrator logical-access logs: a congruous period of not less than six months; MULYAI uses six months as the default minimum-compliance period, with longer retention only where another legal rule or a specific security investigation/legal hold/claims need requires it.
Billing/tax: not active during free beta. If later activated, statutory accounting/tax retention rules apply separately.
Backups: active-system deletion must propagate through the documented backup lifecycle. Deleted accounts must not be restored into ordinary use from backups; restored data must be re-deleted/suppressed before normal processing.
11. ACCOUNT CLOSURE AND LOCAL WORK MEMORY
Closing/deleting your customer account revokes central account/device authorization and starts central deletion/anonymization under the rules above. It does not silently delete local Work Memory on your computer.
Local Work Memory remains under local user-control. Use the product’s local delete/reset/uninstall controls if you also want local data removed. Central commercial/account revocation must never be used to hold local Work Memory hostage.
12. YOUR GDPR RIGHTS
Subject to applicable law, you may have rights to:
- access personal data and processing information;
- correct inaccurate profile data;
- delete personal data where the right applies;
- restrict processing;
- object to processing based on legitimate interests;
- data portability where Article 20 applies;
- complain to a competent supervisory authority, including the Italian Garante where applicable.
To exercise a right, contact gabriellagziel@gmail.com or use an available in-product/account privacy route. We may verify your identity proportionately. We normally respond without undue delay and within one month, subject to lawful extensions.
For an objection to legitimate-interest telemetry/segmentation, we will assess whether compelling legitimate grounds override the objection or whether the processing must stop. Direct marketing, if introduced, would be stopped on valid objection according to applicable law.
13. AUTOMATED DECISION-MAKING / PROFILING
The approved beta is not intended to make solely automated decisions that produce legal or similarly significant effects about you under GDPR Article 22. MULYAI may locally learn recurring work and propose automation, but the approved beta is not an employer employee-scoring/hiring/credit/insurance/essential-service decision system. If this changes, the privacy/legal model must be reopened before activation.
14. SECURITY
The current beta design uses data minimization, TLS, controlled backend access, separate admin identity/least privilege, pseudonymous identifiers, local AI, strict telemetry allowlists and audit evidence.
Current Windows Work Memory is encrypted locally using SQLCipher, with key material protected for the current Windows user through Windows DPAPI. Private Work Memory/work semantics are deliberately kept outside the central system by default.
The current Windows beta installer may be unsigned for Authenticode. MULYAI discloses that state before download and does not represent the installer as signed. Release integrity/version controls and secure delivery remain required, and code signing is to be reassessed before broader paid/general distribution.
No security system is perfect. If a personal-data breach occurs, MULYAI follows its incident/breach runbook and applicable notification requirements, including supervisory notification where required and communication to affected users for high-risk breaches where applicable.
15. COOKIES / LOCAL STORAGE / TRACKING
Approved beta policy: strictly necessary/functional storage only; no Google Analytics, Meta Pixel, advertising pixels, retargeting, session replay, heatmaps or behavioral advertising profiling.
Current website/app-browser storage identified for MULYAI includes:
- localStorage key “mulyai-language” for language preference;
- sessionStorage for the current Investor Access token during the browser session;
- an Investor refresh cookie named “mulyaiInvestorRefresh” with HttpOnly, Secure and SameSite=Lax attributes and a maximum age of 30 days.
Authentication/security infrastructure may also use strictly necessary technical mechanisms as required to provide the requested service.
The current live mulyai.com homepage does not load Google Fonts from fonts.googleapis.com/fonts.gstatic.com.
Under Italian Garante guidance, a consent banner is not required solely for technical/strictly necessary cookies/storage; transparent information remains required. If non-essential tracking or marketing technologies are later added, they will be blocked/subject to the consent rules then applicable.
16. CHILDREN
The open beta is for adults aged 18+. We do not intentionally offer beta registration to children or collect date of birth. If we learn an account was created contrary to the age requirement, we may close it and handle data according to applicable law.
17. EMPLOYER / THIRD-PARTY INFORMATION
If you use MULYAI on work connected to an employer, you are responsible for having the rights/permissions required for local use. MULYAI does not contact your employer by default and does not centrally receive your substantive work content by default. This does not remove MULYAI’s own obligations for data it actually receives.
18. AI TRANSPARENCY
MULYAI is an AI system. In the beta it uses local AI to learn/reason about recurring work and is intended for personal productivity/work assistance.
Where users interact directly with AI functionality, MULYAI should make the AI nature of that interaction clear where it is not already obvious from the circumstances. MULYAI maintains proportionate AI-literacy measures appropriate to its operator/use context.
The beta is not offered for employer employee scoring/performance evaluation, hiring ranking, biometric/emotion analysis, credit/insurance/essential-service eligibility, law-enforcement/migration/judicial decision-making or other high-consequence automated decision purposes. If this changes, the privacy/legal model must be reopened before activation.
19. CHANGES
Material changes to data categories, purposes, cloud AI, telemetry, processors, tracking, investor-access processing or execution/control architecture require privacy impact review and an updated Policy before activation where required.
Material legal revisions receive a new version/effective date and re-acknowledgement where required. Existing accepted versions and their acceptance evidence are preserved rather than silently overwritten.
20. LANGUAGE
This Policy is intended to be version-aligned in English, Italian, Hebrew and Spanish. For users in Italy, the Italian version controls in case of conflict to the extent lawful; outside Italy, English is the reference version unless mandatory local law requires otherwise.
21. SUPERVISORY AUTHORITY
You may lodge a complaint with a competent data-protection authority. In Italy: Garante per la protezione dei dati personali. Current official contact/complaint information is available from the Garante’s website.
© 2026 Gabriel Lagziel. All rights reserved.