Data Policy

#1. Purpose and Scope

This Data Policy describes how a2sys Co., Ltd. (주식회사 에이투시스), a company established under the laws of the Republic of Korea ("Company," "we," "us," or "our"), processes Customer Content, Request Metadata, and Operational Records in providing inference services to approved marketplaces and platforms. It forms part of the Terms of Service. Capitalized terms not defined here have the meanings given in those Terms.

Sections 2 through 5 describe our retention and use commitments. Sections 6 through 13 ("Data Processing Terms") govern personal data processed on the Customer's behalf, including personal Request Metadata to the extent processed in that role. They supplement and do not reduce the commitments in Sections 2 through 5.

Personal data processed for our own billing, security, and administrative purposes is also covered by the Privacy Policy. This Policy's applicable metadata and record safeguards continue to apply to that processing. Website, inquiry, business contact, and recruitment processing is described separately in the Privacy Policy. The marketplace's independent processing is governed by its own policies; these commitments cover the Company and service providers it engages for the relevant processing.

#2. Zero Data Retention for Customer Content

1. 2.1 Customer Content is processed only transiently in volatile memory to provide the Services and is not written to persistent storage, logs, or databases. This is the Company's Zero Data Retention ("ZDR") commitment.

   The inference engine may retain intermediate state derived from Inputs, such as attention key-value cache entries, in volatile memory after returning an Output to avoid repeating computation on subsequent requests. This state does not survive a restart of the inference process. It is evicted when memory is reclaimed; during low demand, it may remain until a restart or redeployment. There is no fixed time-based expiry for this in-memory cache. Termination is addressed in Section 11.5.

   The inference infrastructure is shared: cached state is not isolated by Customer or end user and may be reused for a matching prefix in a subsequent request from another Customer or end user. Responses report the number of cached tokens for the request. This description is not a representation that caches are tenant-isolated. Cache reuse is limited to providing the Services; it does not authorize disclosure of another user's Customer Content or waive the Company's confidentiality and security duties. The cached state is not written to persistent storage.

2. 2.2 Customer Content is not used to train, fine-tune, evaluate, or otherwise improve any machine learning or artificial intelligence model for the Company or any third party.

3. 2.3 ZDR applies to all models, endpoints, features, and failed requests supplied as part of the Services. Customer Content, including content-bearing fragments of request parameters, is excluded before records are written to local or centralized logs. This includes application, gateway, access, error-diagnostic, observability, and log-collection paths. Customer Content is not persisted in dumps, snapshots, disk-backed caches, or backups. The Company does not keep content logs for troubleshooting, quality assurance, or abuse investigations. Section 4.6's 30-day period applies only to non-content logs and creates no exception to these commitments.

#3. Request Metadata and Operational Records

1. 3.1 "Request Metadata" is limited to the following non-content fields, collected where relevant to the request and purposes below:

• request identifier, model identifier, and model group or provider routing category;
• input and output token counts, request timestamp and latency, and computed cost;
• an identifier for the marketplace API credential, not the secret credential itself;
• user, team, organization, or session identifiers supplied for service operation where applicable;
• permitted technical request tags;
• the connection address and User-Agent, as exposed at the relevant network or gateway layer; and
• the call type, response status, and whether the request used cached inference state.

Gateway connection addresses generally describe the upstream proxy; load-balancer records may identify the connecting marketplace. We do not equate a proxy address with an end user's device address or assume that these fields can never be personal data.

1. 3.2 Metadata collection uses permitted fields and technical values, not the content of Inputs or Outputs. The Customer must not submit prompt text, output text, credentials, or unnecessary personal data through identifier or tag fields. Content-bearing values are excluded from logs rather than being treated as non-content simply because they appear in a metadata field.

2. 3.3 "Operational Records" comprise (a) non-content diagnostics, limited to timestamps, request or resource identifiers, service and component identifiers, response or error codes, durations, counts, and fixed technical event categories; and (b) cloud administrative audit records describing infrastructure management actions, such as administrator identity, calling address, resource identifier, action, time, and result. Free-text request parameters and Customer Content are not diagnostic fields. Administrative records are separate from request-level billing records and do not contain Customer Content. The Privacy Policy also applies where these records contain administrator or other personal data.

#4. Purposes and Retention

1. 4.1 Request Metadata is used only as needed for request handling, usage and rate limits, service security, billing, reconciliation, and investigation of billing discrepancies. Operational Records support fault diagnosis, availability, security, and accountability for infrastructure management. The Company limits identifiable fields to what each purpose requires.

2. 4.2 Request-level billing records are retained for 365 days from the request to support reconciliation and billing disputes. These records are limited to request and marketplace credential identifiers, model and routing information, token counts, timestamps, latency, cost, status, call type, and cache usage relevant to settlement. User and session identifiers, raw request tags, and connection headers are not retained for 365 days merely because they accompanied a billable request; operational copies are subject to Section 4.6. Where a specific law requires longer retention of particular financial records, only those necessary records are segregated or access-restricted and retained for the required period. The exception does not apply to Customer Content.

3. 4.3 The Company derives daily aggregate usage totals for operational reporting. Totals may be retained without a fixed end date only if they do not identify and cannot reasonably be linked to a natural person. Merely grouping records by Customer or replacing names with identifiers does not establish anonymity. Identifiable totals remain subject to the relevant personal-data limits.

4. 4.4 Infrastructure metrics contain non-content counts, latencies, resource measurements, and limited technical labels. Applicable Cloud Monitoring series, including Managed Prometheus and supported cloud service metrics, are retained for up to 24 months; other metric types have shorter periods, including six weeks. Reduced sampling resolution does not mean the records have been deleted. Customer Content, end-user identifiers, session identifiers, and free-text request tags are not used as metric labels.

5. 4.5 Billing records deleted under Section 4.2 may remain in routine database backups for no more than seven additional days. Backup access is restricted to recovery, and deletion rules are reapplied if a backup is restored. This extension does not apply to Customer Content or extend the 30-day limit for access and error-diagnostic logs.

6. 4.6 API access and non-content operational error-diagnostic logs, including local records and centralized copies, are deleted no later than 30 days after creation. The limit is enforced by age from creation, not solely by log size or file count. Log forwarding does not restart the period. Operational user, session, tag, and connection fields are subject to the same limit.

7. 4.7 Cloud resource administration audit records are retained for up to 400 days under the cloud service's administrative audit schedule. They are separate from the 30-day request diagnostics and the 365-day billing records. Their purpose, personal-data handling, and overseas processing are also explained in the Privacy Policy.

#5. Access to Metadata and Operational Records

Access is limited to authorized personnel and engaged providers who need the information for the purposes in Section 4, subject to appropriate access controls and confidentiality obligations. Requests for assistance should use request identifiers and non-content diagnostics rather than copies of prompts or responses. Access to transient Customer Content is governed by Section 13. Lawfully compelled disclosure is limited to what is required, with notice to the Customer where legally permitted and relevant to its data.

#6. Roles and Application of the Data Processing Terms

1. 6.1 The Customer is a controller or, where acting for an upstream controller, a processor authorized to appoint the Company as a subprocessor. The Company acts as processor or subprocessor for personal data in Customer Content and for personal Request Metadata to the extent processed solely on the Customer's behalf (together, "Customer Personal Data"). The relevant controller determines the purposes of that processing; the Customer transmits authorized instructions through the contractual chain.

2. 6.2 Sections 6 through 13 apply to Customer Personal Data. They do not reduce the ZDR commitments for any Customer Content, whether or not it is personal data. Where a law imposes additional mandatory processing terms, the parties will document those terms in the applicable data-protection instrument before the affected processing.

3. 6.3 The Company acts as an independent controller to the extent it determines its own necessary purposes for marketplace billing, reconciliation, security, and infrastructure administration. The applicable Privacy Policy and Sections 3 through 5 govern that processing. Roles depend on the actual purpose and activity, not solely on the label "metadata." An independent purpose does not authorize reuse of Customer Content. Section 12 also addresses Security Incidents affecting personal Request Metadata processed by the Company as a controller, under the more limited notice standard set out there.

#7. Documented Instructions

1. 7.1 The Company will process Customer Personal Data only to provide the Services under the agreement and the Customer's documented, lawful instructions, including agreed configurations, API requests, and additional written instructions consistent with the agreement. If law requires other processing, the Company will notify the Customer before that processing unless legally prohibited. Neither this clause nor an instruction permits voluntary retention of Customer Content inconsistent with Section 2.

2. 7.2 The Company will not use Customer Personal Data processed on the Customer's behalf for its own advertising, marketing, model training, fine-tuning, evaluation, or model improvement. Independent handling of other personal data is confined to Section 6.3.

3. 7.3 If the Company considers an instruction to infringe applicable data-protection law, it will promptly inform the Customer and may suspend the affected processing while the parties resolve the issue. The parties will agree any lawful change in scope, cost, or technical implementation before additional processing begins, without limiting mandatory rights or assistance duties.

#8. Details of Processing

1. 8.1 Subject matter: Providing inference services and related non-content request handling to the marketplace Customer.

2. 8.2 Duration: For the term of the affected Services, subject to the transient cache lifecycle in Section 2.1, the applicable metadata periods in Section 4, and termination processing under Section 11.5. This does not authorize retaining Inputs or Outputs.

3. 8.3 Nature and purpose: Receiving and transmitting requests, processing Inputs in volatile memory to generate Outputs, transient inference caching as disclosed in Section 2.1, and handling associated non-content metadata under authorized instructions.

4. 8.4 Data categories: Personal data contained in the Inputs and Outputs the Customer is lawfully entitled to submit or receive, and the personal Request Metadata processed on its behalf. Content can contain different categories of personal data, including sensitive data; this description is not permission to submit data without the legal basis and safeguards required for that category. The Company does not inspect Customer Content to categorize personal data.

5. 8.5 Data subjects: Marketplace end users, people described in Customer Content, and individuals associated with the relevant request identifiers. The Services do not require direct retail accounts with the Company.

#9. Subprocessors and Processing Locations

1. 9.1 The Customer gives general authorization to engage subprocessors for the Services, subject to this Section. Inference infrastructure is supplied through Elice Cloud, operated by ELICE INC., and Google Cloud supports gateway, network, database, logging, and monitoring functions. The Subprocessors page identifies the relevant legal entities, functions, data categories, and processing locations. A provider handling only the Company's independent controller records is not, for that reason alone, a subprocessor of Customer Personal Data. Website, inquiry, and recruitment providers are described separately in the Privacy Policy.

2. 9.2 Before a subprocessor processes Customer Personal Data, the Company will bind it by a written agreement imposing the data protection obligations required by applicable law, including the same relevant obligations as these Data Processing Terms. The Company remains responsible to the Customer for that subprocessor's performance to the extent required by applicable law and the parties' agreement. A subprocessor may not retain or use Customer Content contrary to Section 2.

3. 9.3 Inference computation takes place on GPU infrastructure in the Republic of Korea. The API gateway, billing database, and designated API access-log storage are in the Seoul region. Routine database backups are stored in a multi-region location that is not limited to Korea. Local inference diagnostic logs are processed on the inference nodes in Korea. Google's global network infrastructure may terminate TLS and handle requests outside Korea before forwarding them to the Korean backend. Consequently, domestic inference and designated storage do not mean that all processing occurs exclusively in Korea.

   Cloud administrative audit records use storage that is not limited to Korea. Monitoring and other management functions have separate processing locations. These statements do not authorize Customer Content to be included in such records. For transfers of Customer Personal Data, the Company will comply with applicable transfer law, obtain any required authorization, and provide required information and safeguards before the transfer. An applicable adequacy decision may be used within its scope; otherwise the required valid transfer mechanism must be established. General authorization of a subprocessor is not itself a substitute for a required transfer mechanism or information-subject notice.

4. 9.4 The Company will post an intended addition or replacement of a subprocessor on the Subprocessors page at least 30 days before the change. The parties agree that this posting is the notice method for this Section, so Section 17.4 of the Terms does not require separate direct notice for a subprocessor change. The Customer may object during that period on reasonable data-protection grounds by contacting the Company at infra@a2sys.ai. The parties may discuss alternatives, but the Company is not required to develop or procure a different provider or configuration. If the objection cannot be resolved, either party may terminate the affected Services, with settlement under the Terms. Customer Personal Data will not be sent to the proposed subprocessor while a timely objection remains unresolved; the affected processing may be suspended if necessary.

#10. Customer Responsibilities

1. 10.1 The Customer must have authority to submit Customer Personal Data and issue processing instructions, and must ensure that the relevant controller has established the required legal bases, notices, consents where needed, and safeguards. Where the Customer is itself a processor, it must obtain the required upstream authorization to appoint the Company. The parties will reasonably cooperate in providing information needed for lawful processing and transfers. These responsibilities do not relieve the Company of obligations applicable to its own conduct or independent controller processing.

#11. Confidentiality, Security, Assistance, and Deletion

1. 11.1 The Company will keep Customer Personal Data confidential. Personnel authorized to process it must be bound by contractual or statutory confidentiality duties. Disclosure is limited to authorized processing under the agreement or a binding legal requirement, subject to legally permitted notice and minimum disclosure. Transient cache reuse is not an exception to confidentiality.

2. 11.2 The Company will maintain technical and organizational measures appropriate to the processing and its risks, including access control, transport protection, content exclusion from persistent logs, retention enforcement, and controls on personnel and provider access. The Company will provide the Customer with information about relevant measures on reasonable request.

3. 11.3 Taking account of the nature of processing and information available, the Company will assist the Customer with data subject requests, security obligations, breach response, data protection impact assessments, prior consultation, and regulator inquiries required by applicable law. It will promptly forward a request concerning Customer Personal Data to the Customer unless prohibited by law, and will not respond on the Customer's behalf without authorization except where law requires a response.

4. 11.4 The Company will make available information reasonably necessary to demonstrate compliance with these Data Processing Terms and allow and contribute to audits and inspections by the Customer or a qualified independent auditor bound by confidentiality. The parties will use existing reports where sufficient and agree reasonable scope, notice, timing, and protection of other customers' data. Routine audits will normally occur no more than annually, but that limit does not restrict audits required by law, a regulator, or documented evidence of a material breach identified by the Customer in writing. The Customer bears the costs of audits it initiates, except where the audit identifies the Company's material non-compliance; charges will not defeat mandatory rights, and the Company bears its own remediation costs for its non-compliance. An audit does not entitle an auditor to other users' content or require the creation of persistent Customer Content records.

5. 11.5 When the affected Services end, the Company will cease content processing; remaining in-memory inference state is evicted in the ordinary course and does not survive the next restart or redeployment of the affected inference process. For other Customer Personal Data it holds on the Customer's behalf, it will, at the Customer's choice, return or delete the data and delete copies without undue delay and no later than 30 days, unless applicable law requires retention. Database backup expiry remains subject to Section 4.5. The 30-day administrative deadline does not authorize preserving Customer Content or extending its transient cache lifecycle. The Company need not reconstruct or create a stored copy of content it does not retain. Independently controlled billing and administrative records follow Section 4 and the Privacy Policy. On reasonable request, the Company will confirm completion of its deletion obligations for data it retains.

#12. Security Incident Notification

1. 12.1 A "Security Incident" means a breach of security leading to accidental or unlawful destruction, loss, alteration, falsification, damage, unauthorized disclosure of, or access to Customer Personal Data or personal Request Metadata processed by the Company. For Customer Personal Data, the Company will notify the Customer without undue delay after becoming aware of an incident affecting such data and, in any event, within 72 hours, or sooner where applicable law or the parties' agreed incident terms require. This is an outer contractual limit, not a right to postpone notice or await completion of an investigation. Where applicable law requires notice upon awareness of a possibility of such an incident affecting Customer Personal Data, the Company will meet that earlier trigger. For a Security Incident affecting personal Request Metadata processed by the Company as a controller, the Company will inform the Customer without undue delay to the extent relevant to the Services.

2. 12.2 Initial notice will include the nature of the incident, affected data and data subjects, likely consequences, available mitigation steps, and an incident contact, to the extent known. Additional information, including approximate numbers and response measures, may be provided in phases without undue further delay. Lack of a complete investigation does not delay initial notice.

3. 12.3 The Company will reasonably cooperate in containment, investigation, remediation, and the Customer's legally required notices and reports. The Company separately fulfills any notice or reporting duties applicable to its own controller processing; informing a marketplace is not a substitute for those duties.

4. 12.4 ZDR reduces retained content but does not eliminate the possibility of an incident during transient processing, including in-memory caching or transmission. Nothing in this Section excludes such incidents or creates permission to store Customer Content for an investigation. Required records of response activities must exclude Customer Content.

#13. Access to Transient Customer Content

1. 13.1 Routine access to Customer Content is limited to automated inference processing and network delivery needed to provide the Services, including the transient cache operation described in Section 2.1, subject to the exceptional access in Section 13.2.

2. 13.2 Company personnel have no standing access to Customer Content. A limited number of authorized personnel may receive temporary, least-privilege access to system state during response to a service disruption, only where necessary to diagnose and resolve it. Access must be authorized, limited in duration, and recorded with the person's identity, time, reason, and action, without copying Customer Content into the access record. No persistent dump or content log is permitted. Access is removed when no longer needed.

3. 13.3 Access to Request Metadata and Operational Records is governed by Section 5.

#14. Relationship to Other Documents

This Policy forms part of the Terms of Service. Section 6 of the Terms controls conflicts between those Terms and this Policy concerning Customer Content or Request Metadata, subject to the document precedence and mandatory-law protections in Section 17.3 of the Terms. The Privacy Policy also governs personal data processed for the Company's own purposes. No precedence provision reduces statutory data subject rights or permits a ZDR reduction without the specific agreement required by Section 15.1 of the Terms.

#15. Changes to This Policy

Updates are published on the Data Policy page with a revised date. A material adverse change to the commitments in Section 2 or Sections 6 through 13, including changes to data categories, purposes, security protections, or processing obligations, follows the direct-notice and acceptance requirements of Section 15 of the Terms of Service; website publication, silence, or automated API traffic is not sufficient acceptance for that change. A reduction in ZDR requires specific express written agreement. Changes to retention periods set by a cloud service provider's own schedule, such as those in Sections 4.4 and 4.7, are reflected by posting an updated page with a revised date rather than the acceptance requirement of this Section. Subprocessor changes also follow Section 9.4 of this Policy.

#16. Contact

Questions about this Data Policy may be directed to infra@a2sys.ai.