DPA / AVV under Article 28 GDPR · Version 1.0 · 10 September 2026
| Item | Contractual identification |
|---|---|
| Customer / controller | Full legal name, legal form and address as recorded in the relevant order, main agreement or documented registration and acceptance process. |
| Main agreement / account | The agreed order or service plan and corresponding account reference apply and are linked to the acceptance record. |
| Instruction contact | The authorised contact documented in the order or Customer account and any further persons designated by the Customer in text form. |
| Privacy / incidents | The Customer’s designated privacy or incident contact; until separately designated, the documented authorised contact. The Customer keeps contact details and urgent contact routes current. |
1.1The processor is AP Digital Solutions GbR, Schultestraße 25, 57076 Siegen, Germany, operator of the LEXURA service (the “Processor”). Contact: info@lexura.solutions.
1.2The contracting party and, ordinarily, controller is the customer identified in the relevant order, main agreement or documented registration and acceptance process (the “Customer”). This DPA applies to processing in the course of the Customer’s business, professional or public-sector activities. “Customer Data” means all personal data processed by the Processor on the Customer’s behalf in providing the agreed services. The definitions in Regulation (EU) 2016/679 (“GDPR”) apply.
1.3To the extent LEXURA processes personal data for its own contract administration, billing or compliance with its own legal obligations, it acts as an independent controller and that processing is outside this DPA. Classification depends on the actual purpose, not merely the type of data. User administration and security logs used exclusively to deliver the instructed service remain within scope. Contract content, prompts and outputs may not be reclassified as LEXURA’s own business data to permit other uses.
1.4Where the Customer itself acts as a processor for particular Customer Data, LEXURA acts as its subprocessor. Before processing starts, the Customer notifies LEXURA in text form of its role, the relevant controller and the processing scope, obtains the required authorisation and passes on that controller’s binding instructions. These details are recorded with the order documentation. This DPA applies correspondingly without changing the parties’ actual roles or the relevant controller’s mandatory rights.
2.1The subject matter is AI-assisted contract analysis and standard document generation (including NDAs, framework, consulting and employment agreements) as a software service through the agreed web, email and MCP (Model Context Protocol) interfaces, including hosting, output delivery and support. Annex 1 describes the processing. This DPA does not expand the agreed service scope or create a lawyer-client engagement.
2.2This DPA must be concluded before processing on the Customer’s behalf starts, including any trial or free use. It applies for the duration of the commissioned processing and until Customer Data has been fully returned or deleted under clauses 8 and 11. Keeping an account open does not extend those retention periods.
2.3Annexes 1 to 3 and a versioned service-specific processing specification (the “Processing Specification”) form part of this DPA. LEXURA supplies the Processing Specification in a form that can be retained before this DPA is concluded and before the relevant processing starts. It specifies the recipients and processing chains, processing and access locations, transfer mechanisms, technical implementation details and binding maximum deletion periods required by the annexes. A standard specification may apply to multiple customers of the same service. The relevant processing may start only once the complete specification has been supplied and agreed with this DPA; the Customer must not submit Customer Data for that processing beforehand. Unidentified recipients, unresolved transfers and unconfirmed technical arrangements are not given blanket authorisation.
3.1Processing is solely to provide the commissioned LEXURA functions in accordance with the Customer’s documented instructions. Annex 1 specifies operations, data types, categories of data subjects and scope. Disclosures to authorised AI providers must be limited to content necessary for those purposes.
3.2Within its respective role, the Customer is responsible for lawful instructions, authority to provide the data, required legal bases and notices, and selecting appropriate content and users. It minimises the data submitted and removes unnecessary information where compatible with the purpose. The Processor’s own statutory and contractual obligations remain unaffected.
3.3The standard engagement does not provide for intentional processing of special-category data under Article 9 GDPR or data under Article 10 GDPR. Such processing requires a prior documented agreement on its permitted scope and additional safeguards. If such data is inadvertently submitted and identified, the Processor continues to protect it, restricts further processing to what is necessary and promptly seeks instructions for lawful handling; uploading it does not replace the required agreement.
3.4Specific requirements for professional secrets or information subject to special statutory protection must be disclosed in advance and, where required, separately agreed. This DPA does not replace any necessary secrecy or service-provider engagement agreement. The standard service does not include a solely automated decision producing legal or similarly significant effects under Article 22 GDPR; the Customer is responsible for evaluating and using outputs.
4.1The Processor processes Customer Data only on documented instructions. This DPA, the agreed service description and contract-compliant use of enabled product functions (including upload, analysis, generation, export and deletion) constitute the initial instructions. Transfers and access are also subject to clauses 7 and 9. Adding a function does not authorise processing for unrelated purposes.
4.2Additional instructions are issued in text form, including email, by designated or demonstrably authorised persons. Urgent oral instructions must be documented promptly. The Processor may reasonably verify authority without unduly delaying urgent protective measures. Changes to contacts or authorisations must be communicated promptly.
4.3If the Processor considers an instruction to infringe the GDPR or other applicable Union or Member State data-protection law, it informs the Customer immediately. It may suspend the affected processing to the extent necessary pending lawful resolution, while continuing to protect the data. This does not create an obligation to provide general legal advice or comprehensively assess all Customer content.
4.4Where Union or Member State law requires processing without instructions, the Processor informs the Customer of that legal requirement before processing, unless that law prohibits notification on important grounds of public interest. Clause 9.4 additionally applies to demands from third countries.
4.5Neither the Processor nor its subprocessors may use Customer content, prompts or outputs for general model training, fine-tuning, advertising, sale, public examples or independent product improvement. The Processor imposes corresponding restrictions and does not enable optional sharing for those purposes. Necessary security and abuse controls of an authorised provider are permitted only within the specifically described, instructed scope in Annexes 1 and 3; they do not permit use as training material.
5.1Before access is granted, the Processor ensures that all persons authorised to process data are bound to confidentiality, unless already subject to an appropriate statutory duty. The obligation also covers confidential non-personal contract content and survives the end of their work and this DPA.
5.2Access is limited to authorised persons and what is necessary for their tasks. The Processor provides risk-appropriate training, reviews permissions and revokes access no longer needed. It maintains required processing records and appoints a data protection officer where legally required; a privacy contact is always reachable at info@lexura.solutions.
5.3The Processor promptly informs the Customer, where legally permitted, of official measures, seizures or other circumstances materially jeopardising compliant processing. It complies with statutory information and cooperation duties, assesses the lawfulness of disclosure demands and limits disclosures to what is necessary.
6.1Before and throughout processing, the Processor implements the technical and organisational measures (“TOMs”) agreed in Annex 2, as detailed in the Processing Specification. Security must meet Article 32 GDPR, taking account of the state of the art, implementation costs, the nature, scope, context and purposes of processing, and risks to individuals’ rights and freedoms.
6.2The measures address, as appropriate to the risks, confidentiality, integrity, availability and resilience, restoration following incidents, and regular testing and evaluation of effectiveness. The Processor’s security responsibility includes its web, email and MCP interfaces; use of those interfaces does not waive its obligations.
6.3The Processor may improve measures or replace them with measures providing at least equivalent protection. The agreed protection level may not be reduced. Material changes are documented and communicated to the Customer; changes to subprocessors or processing locations are additionally subject to clauses 7 and 9.
7.1The Customer gives general authorisation under Article 28(2) GDPR for the subprocessors specifically identified in the agreed Processing Specification in accordance with Annex 3, within the stated scope. The Processor maintains current identity, address, privacy contact, activity and processing-location information, including the relevant further processing chain, and proactively makes it available to the Customer in a durably accessible form that can be retained. A brand or provider label alone does not authorise an unidentified legal entity.
7.2Before appointment, the Processor assesses the subprocessor’s suitability and concludes a written or electronic agreement imposing, to the relevant extent, the same data-protection obligations as this DPA. These include instructions, confidentiality, TOMs, assistance, deletion and permitted further appointments and transfers. The Processor’s responsibility under Article 28(4) GDPR remains unaffected.
7.3The Processor notifies the designated Customer contact of intended additions or replacements at least 30 calendar days before use by email or an equivalent directly addressed, retainable message. The notice includes the information in clause 7.1 and necessary transfer details. Updating a website alone is insufficient. The Customer may object on reasonable data-protection grounds within 14 calendar days after receiving complete information; the notice draws attention to that period.
7.4Following a timely objection, the parties seek a compliant, commercially reasonable solution. The disputed provider receives no affected Customer Data pending resolution. If no such solution is available, either party may terminate only the affected service without penalty; prepaid fees for services no longer to be supplied are refunded proportionately. In the absence of a timely objection, use may begin after the notified lead time under the general authorisation. Statutory objections and rights remain unaffected.
7.5Email services, MCP clients or other third-party systems independently selected by the Customer do not become LEXURA subprocessors merely because they are connected. The Customer addresses their separate processing within its responsibilities. Recipients actually engaged by LEXURA to deliver the service remain subject to clauses 7 and 9; labelling them integrations or Customer tools does not avoid those duties.
8.1Uploaded contract files and generated outputs ordinarily have a retention period of 90 calendar days from the respective upload or creation. At expiry, ordinary availability and authority for further active processing end; technical deletion follows Annex 2 and the implementing Processing Specification without undue delay. This is not deletion immediately after analysis. Different periods require a documented agreement.
8.2Earlier authorised deletion instructions, including confirmed account deletion, are implemented without undue delay under the agreed deletion process. Maximum periods and triggers for live systems, versions, working copies, emails, logs and backups must be specified and agreed in the Processing Specification under Annex 2 before processing starts. Earlier action required by law takes precedence. The Processor also arranges necessary deletion by its subprocessors.
8.3Backup copies that cannot technically be deleted individually at once are isolated and protected against ordinary access until final deletion within the maximum period agreed in the Processing Specification under Annex 2. They may be used only for necessary restoration, with deletion instructions reapplied before renewed live use. Backup retention does not extend the 90-day active-storage period. Hiding data or expiring a download link does not constitute deletion.
8.4Further retention by the Processor after the processing engagement ends is permitted only where Union or Member State law requires it. Where lawful, the Customer is informed of the legal basis, data scope and duration; the data is isolated, protected for that limited purpose and subsequently deleted. The Processor’s own statutory retention duties for invoices do not justify blanket retention of underlying Customer documents.
9.1The described application and object storage is in AWS eu-central-1 (Frankfurt); the described Cognito authentication is in AWS eu-west-2 (London). The United Kingdom is outside the EEA. Actual AI-provider and other recipient processing and access locations must be recorded in the agreed Processing Specification under Annex 3. Calling an API from Frankfurt does not establish EU-only or EEA-only processing.
9.2Where Chapter V GDPR applies, transfers take place only on documented instructions and under an adequacy decision under Article 45 GDPR covering the particular recipient and operation, or appropriate safeguards under Article 46 GDPR. Required standard contractual clauses (“SCCs”) must be validly concluded with the correct parties, applicable module and completed annexes. Required transfer assessments and supplementary measures must be completed and documented beforehand. This DPA replaces neither SCCs nor a transfer assessment.
9.3The Processor verifies the transfer mechanism, including relevant remote access and onward transfers, and makes necessary evidence available to the Customer. If a mechanism ceases to apply or cannot be complied with, it promptly informs the Customer and suspends the affected transfer until a lawful solution is in place. Return, deletion or termination of the affected service follows where necessary; mandatory SCC provisions prevail.
9.4For access demands by foreign authorities, the Processor assesses Article 48 GDPR and applicable transfer requirements in particular. Foreign law does not create a blanket exception to instructions. Where legally permitted, it informs the Customer before disclosure and uses appropriate legal remedies against unlawful or disproportionate demands.
10.1Taking account of the nature of processing, the Processor assists the Customer through appropriate TOMs, insofar as possible, with requests under Chapter III GDPR. It promptly forwards requests received directly about Customer Data; substantive responses are given only on instructions or where legally required. It assists with necessary correction, deletion, restriction and provision of data.
10.2Taking account of the nature of processing and information available to it, the Processor assists the Customer with obligations under Articles 32 to 36 GDPR, including security assessments, notifications, data protection impact assessments and prior consultation. It provides necessary information and cooperates with competent supervisory authorities as required by law.
10.3The Processor notifies the designated Customer contact of a personal data breach affecting Customer Data without undue delay after becoming aware of it. The initial notice includes available information on nature and scope, affected data and individuals, approximate numbers, likely consequences, measures taken or proposed and a contact point. Missing information follows without undue delay; notification must not await completion of the investigation.
10.4The Processor promptly takes necessary containment and remediation measures, preserves necessary evidence proportionately and assists with the Customer’s notification duties. A notification is not, by itself, an admission of liability. The Customer’s responsibility for its own notifications and the Processor’s own statutory duties remain unaffected.
10.5The Processor makes available all information necessary to demonstrate compliance with Article 28 GDPR and allows for and contributes to audits, including inspections, by the Customer or a competent auditor it appoints. Suitable current documents, independent reports and remote reviews should be used first where they enable effective verification. They do not replace an on-site inspection where one is necessary.
10.6Routine audits ordinarily require 15 Working Days’ notice, take place during normal business hours and occur no more than once in twelve months. These limits do not apply to authority requirements, personal data breaches, substantiated doubts about compliance, material audit-relevant changes, or where additional or earlier audits are legally necessary. Working Days are Monday to Friday excluding public holidays in North Rhine-Westphalia. Audits must be appropriately scoped and confidential; suitable safeguards protect other customers and trade secrets without preventing necessary evidence or statutory disclosures.
10.7Ordinary compliance with this DPA, including necessary evidence, standard assistance, return and deletion, is included in the agreed service fees. Transparent, reasonable charges may be agreed in text form in advance for additionally commissioned services beyond that scope. No additional charge applies to remedying or investigating breaches attributable to the Processor or its subprocessors. Fee discussions must not delay or prevent legally required cooperation; each party ordinarily pays its own externally appointed auditors.
11.1After the services end, all remaining Customer Data is returned or deleted at the Customer’s choice; following return, existing copies are deleted subject to clause 8.4. Return uses a commonly used, usable electronic format and an appropriate secure channel, and covers all in-scope Customer Data still held, not only output files. Termination alone does not waive the right to return.
11.2By this DPA, the Customer generally instructs deletion according to the agreed retention periods, but may give timely alternative return instructions for data still held. On termination, the Processor gives it a reasonable opportunity to exercise that choice before final deletion. A return instruction already received for data still held must be fulfilled before routine deletion of that data. Lawfully deleted data need not be recreated, and permanent archiving is not provided.
11.3On request, the Processor confirms completion of return and deletion, including measures arranged with subprocessors, and identifies any isolated residual copies with their deletion date or mandatory retention basis. Unpaid fees do not create a right to withhold Customer Data. Download links are disabled on expiry or completion of their purpose.
11.4If a material data-protection breach cannot be remedied within a reasonable period, the Customer may terminate the affected service for cause; statutory rights to immediate termination or suspension remain unaffected. Security, return and deletion obligations survive early termination.
12.1The Processor has unlimited liability for intent and gross negligence, injury to life, body or health, fraudulent concealment of a defect, to the extent of an expressly assumed guarantee, and under mandatory statutory liability provisions.
12.2Outside clause 12.1, for ordinary negligence the Processor is liable only for breach of an essential contractual obligation whose fulfilment enables proper performance of the contract and on whose observance the Customer may ordinarily rely; liability is then limited to damage typical of the contract and foreseeable when it was concluded. Liability for other ordinary negligence is excluded. Clause 12.3 remains unaffected.
12.3Data subjects’ rights, particularly under Article 82 GDPR, supervisory authorities’ powers and mandatory statutory responsibilities are neither excluded nor limited. Statutory contribution under Article 82(5) GDPR remains unaffected. This DPA does not create a strict-liability indemnity in favour of the Customer for administrative fines. A blanket monetary liability cap in general website or use terms does not apply to claims under this DPA.
12.4The laws of the Federal Republic of Germany apply, subject to mandatory Union law. Siegen is the exclusive venue for disputes between the parties under this DPA only where such an agreement is validly permitted under section 38 of the German Code of Civil Procedure and applicable Union jurisdiction rules. Otherwise, statutory jurisdiction applies. Data subjects’ rights and mandatory SCC jurisdiction provisions remain unaffected.
13.1Mandatory data-protection law and validly incorporated SCCs prevail. Otherwise, this DPA and its annexes take precedence over conflicting website, use or other standard terms for the processing, confidentiality, liability and dispute resolution governed here. Individually negotiated agreements retain their statutory precedence but may not reduce mandatory data-protection duties.
13.2Any licence in other terms concerning Customer content supplied for the processing engagement is limited to uses necessary for the contracted service and permitted subprocessing, and to their required duration. It does not permit publication, sale, general AI training or other independent exploitation. This DPA is not data-subject consent and does not replace a required legal basis.
13.3This DPA may be concluded by mutual agreement in text form, including email, signature, or recorded electronic acceptance of a corresponding offer by LEXURA by a person authorised to act for the Customer. This specifically identified version, its annexes and the complete Processing Specification must be supplied before acceptance. The parties, acceptance, time, acting person and agreed versions must be retained as evidence and supplied to the Customer in a form that can be retained. Publication or downloading alone does not conclude a contract. Amendments require mutual agreement in text form, without prejudice to permitted updates under clauses 6 and 7. Unilateral website changes or mere continued use do not replace the required agreement.
13.4Where the German and English versions are agreed together, the German version prevails in case of inconsistency. Both versions must then be supplied to the Customer before execution. Where only one language version is agreed, that version is the contractual text; German governing law applies in either case.
13.5Invalidity of an individual provision does not affect the remaining provisions to the extent provided by law, in particular section 306 of the German Civil Code. An invalid standard term is not automatically reduced to the most extensive permissible version.
| Item | Agreed scope |
|---|---|
| Service / purpose | AI-assisted analysis of Customer-supplied contracts and generation of commissioned standard documents; delivery of results and necessary support. No independent use of content by LEXURA. |
| Operations / interfaces | Receipt, transmission, hosting, storage, text extraction, machine analysis, document generation, delivery, access, necessary troubleshooting, export and deletion. Web, email and MCP only as commissioned and enabled. |
| Data types | Where supplied by the Customer: names, roles, business contact details, contracting-party and representative details; employment, remuneration, payment and signature information within contract content; prompts, extracts and outputs reproducing such data. Necessary user, allocation, transmission and security metadata is included only to the extent processed on the Customer’s behalf. |
| Data subjects | The Customer’s employees and other users; individual counterparties, customers, suppliers, advisers and their employees or representatives; other individuals named in supplied files, to the extent necessary for the agreed purpose. |
| Frequency / scope | One-off or repeated operations according to Customer use within the agreed order or service plan. The corresponding account reference and any volume or functionality limits are recorded in the order documentation. This DPA does not extend those limits. |
| Duration / locations | Duration under clause 2; storage and deletion under clauses 8 and 11 and Annex 2. Locations and recipients only as specified under Annex 3 and in the Processing Specification agreed before processing starts. |
| Sensitive data / protection | No intentional Article 9 or 10 GDPR processing in the standard engagement; clause 3.3 applies. Specifically authorised processing and additional safeguards require a prior documented agreement. Professional secrets are subject to clause 3.4 and any necessary separate agreements. |
| Customer role / instructions | The role follows the actual processing operations. Where the Customer itself acts as a processor, it records the controller, scope, required authorisation and instructions under clause 1.4. Instruction and incident contacts are maintained under this DPA’s contract and contact details. |
The measures below are contractual minimum requirements and must be implemented and documented before and throughout processing. The Processing Specification details their actual implementation and must be supplied and agreed before processing starts. This annex does not assert an independent security audit or certification.
| Control area | Contractual measure and documentation |
|---|---|
| T1 · Transmission / encryption | Current TLS-protected transmission at controlled interfaces; encryption of Customer Data stored with the host and restricted key access. No unprotected transmission based on supposed blanket email consent. The Processing Specification describes the protocols, encryption methods and key management used. |
| T2 · Identity / permissions | Cognito authentication and role-based access; least-privilege IAM, regular reviews and prompt revocation of unnecessary permissions. Multi-factor authentication for privileged access and secure secret management. The Processing Specification describes implementation and the review cycle. |
| T3 · Tenants / interfaces | Consistent authorisation and tenant checks across web, email and MCP operations; prevention of cross-tenant access. Secure recipient verification, purpose-limited API keys and time-limited download links. A sender address alone does not authorise arbitrary data access. The Processing Specification describes verification procedures and the maximum validity of download links. |
| T4 · Logs / monitoring | Traceability of relevant access, administrative changes, exports and deletion; protected security logs and risk-appropriate alerting. No routine logging of full contracts, prompts or credentials. The Processing Specification describes recorded events, responsibilities and purpose-based metadata retention. |
| T5 · Development / vulnerabilities | Controlled changes, risk-based vulnerability remediation and separation of test and production environments. No use of live Customer content for development or testing without lawful documented instructions. The Processing Specification describes testing, patching and release procedures. |
| T6 · Availability / restoration | Risk-appropriate resilience and recovery, protected backups where used, and regular effectiveness tests. No separate availability SLA is created here. The Processing Specification describes whether and which backups are used, recovery arrangements, test intervals and deletion cycles. |
| T7 · Personnel / physical security | Confidentiality commitments and documented training, secure endpoints and restricted administrative access; risk-appropriate physical safeguards, including suitable evidence for commissioned data centres. Responsibilities and suitable implementation evidence are documented and made available under clause 10. |
| T8 · Incidents / suppliers | Documented detection, escalation, containment and notification of incidents; reachable responsible persons and current Customer contacts. Supplier data-protection review, effective contracts and change monitoring. The Processing Specification describes responsibilities, escalation routes and the review cycle. |
| Dataset | Binding rule / trigger | Required Processing Specification detail |
|---|---|---|
| R1 · Contracts / outputs | 90 calendar days from the respective upload / creation; earlier deletion instructions prevail. No ordinary access after expiry. | Maximum technical completion period after expiry; handling of versions and replicas; procedures for blocking access and final deletion. |
| R2 · Earlier deletion / service end | Without undue delay after an authorised instruction or the choice under clause 11. | Binding maximum calendar period for live systems from receipt of the authorised instruction or completion of the agreed return. |
| R3 · Backups / residual copies | Ordinary access restricted upon the deletion event; final deletion under the agreed cycle. No extension of live retention. | Existence and types of backups; maximum period and precise starting event for each residual copy; procedure for reapplying deletion instructions on restoration. |
| R4 · Emails / working copies / logs | Only as long as necessary for the engagement; contract-content copies no longer than the agreed content period. Pure metadata requires separate purpose-based limits. | Covered mailboxes, attachments, temporary text, caches, queues, databases and logs; exact periods and deletion procedures for each. |
| R5 · Subprocessors | Full alignment with Annexes 2 and 3, including AI prompts, responses, application state, safety logs and onward recipients. | Actual agreed provider periods, deletion options, permitted exceptions and necessary configuration under Annex 3; evidence of compatibility with Customer instructions. |
The right-hand column identifies mandatory content of the Processing Specification to be agreed before processing, not additional permission to retain data. The specification records its version, date and responsible function. It may not silently extend the 90-day ordinary storage period or earlier deletion required by law. LEXURA documents implementation and effectiveness testing; the affected processing must not begin without defined and implementable maximum periods.
Before processing starts, the Processing Specification identifies the actual contracted legal entities, their processing and relevant onward recipients. It is supplied to the Customer under clause 2.3 and forms part of this annex. The service descriptions below do not, by themselves, authorise an unnamed legal entity or unknown processing locations. New or replacement subprocessors are subject to clause 7.
| Item | Service scope and required specification |
|---|---|
| Legal entity / contact | Amazon Web Services EMEA. The Processing Specification identifies the actual contracted legal entity in full, its address and privacy contact. |
| Activity / data | Hosting, object storage and email delivery; Cognito authentication. Contract content, outputs, email data and necessary user and authentication data, each only to the extent within scope under clause 1.3. |
| Locations / further access | Application and object storage: eu-central-1, Frankfurt, Germany. Authentication: eu-west-2, London, United Kingdom. The Processing Specification also identifies the actual email services and regions, support locations and all relevant further access and subprocessing locations. |
| Contracts / transfers | The Processing Specification identifies the effective provider DPA and version and the relevant processing chain with identities, addresses and contacts. For every covered third-country transfer it specifies the applicable valid adequacy decision or appropriate safeguards under clause 9, including any required transfer assessment and supplementary measures. |
| Deletion / evidence | The actual configured architecture is decisive. The Processing Specification describes deletion of live data, versions, backups, emails and authentication data, with triggers, maximum periods and evidence. Standard provider wording does not replace these details. |
| Item | Service scope and required specification |
|---|---|
| Legal entity / contact | OpenAI API. The Processing Specification identifies the actual contracted legal entity in full, its address and privacy contact; the brand name alone is insufficient. |
| Activity / data | Production of commissioned analyses and documents using necessary prompts, contract text or extracts; return of outputs. The Processing Specification identifies the endpoints, functions, storage parameters and relevant projects used. |
| Locations / access / safety | Invocation from eu-central-1 is not a provider-location commitment. The Processing Specification identifies countries for inference, storage, safety controls and support, and onward recipients. Any human review and safety processing must be specifically described with its purpose, role and limits and may take place only within the agreed, lawful scope. |
| Contracts / transfers | The Processing Specification identifies the effective provider DPA, relevant processing chain and applicable transfer mechanisms. Any required SCCs with the correct parties, module and annexes, and transfer assessments, must be documented beforehand. Unspecified provider changes are not authorised. |
| Training / retention | No opt-in to training or independent product improvement under clause 4.5. The Processing Specification identifies actual retention and deletion periods for prompts, responses, application state, caches and safety logs, including permitted exceptions. Special retention controls or regional processing may be promised only in accordance with the configuration actually contracted and implemented. |
Stripe is used for payment processing. Processing payments solely for LEXURA’s own services does not, by itself, constitute subprocessing for the Customer. LEXURA’s and Stripe’s roles must be determined by actual operations; Stripe may act as a processor or independent controller depending on the operation. Contract files, prompts and analysis content are not transmitted for payment purposes.
To the extent Stripe processes Customer Data on this Customer’s behalf, the Processing Specification must additionally identify the contracted entity, activity, data types, countries, contracts and deletion periods before processing starts. This does not reclassify processing solely of payments for LEXURA’s own services from the role described in clause 1.3.
All other subprocessors actually engaged, including support, email, telemetry or other AI services, and their relevant onward processing chains must be identified in the Processing Specification with the same information. Where none are engaged, this must be expressly recorded there. Actual use of a provider does not replace its required authorisation.
The Processing Specification is linked to the acceptance record by version and date. It contains references to incorporated provider agreements, transfer mechanisms and security and deletion documentation. Changes are made only under the applicable provisions of clauses 6, 7, 9 and 13.
© 2026 · Lexura · All rights reserved