Last Updated: March 2026.
We engineer absolute data security. Zero compromises.
This document constitutes the legally binding Privacy Policy and Data Processing Agreement ("DPA") governing the Syrex multi-tenant agentic AI platform. It is incorporated by reference into the Master Subscription Agreement between Syrex Tech ("Processor") and the contracting entity ("Controller"). Capitalised terms not defined herein shall have the meaning ascribed in the Master Subscription Agreement.
1.1 "Agentic Workflow" means an autonomous or semi-autonomous sequence of computational operations initiated by a natural language prompt, comprising inference invocations, tool calls, external API transactions, and deterministic logic gates, executed by the Platform without continuous human supervision.
1.2 "Communication Channel" means any third-party messaging protocol or telephony interface through which a Data Subject interacts with an Agentic Workflow, including but not limited to OAuth-authenticated session transports.
1.3 "Controller" means the legal entity that determines the purposes and means of the Processing of Personal Data, being the subscriber to the Platform's SaaS services.
1.4 "Data Subject" means an identified or identifiable natural person whose Personal Data is processed through an Agentic Workflow.
1.5 "Ephemeral Context" means session-scoped data resident exclusively within volatile inference state, not committed to any durable persistence layer and irretrievable upon session termination.
1.6 "Platform" means the Syrex multi-tenant agentic AI SaaS platform, including all underlying infrastructure, inference pipelines, orchestration layers, storage subsystems, and administrative interfaces.
1.7 "Processor" means Syrex Tech, the legal entity that processes Personal Data on behalf of the Controller.
1.8 "Tenant Corpora" means the totality of data objects, configuration artefacts, conversation logs, vector embeddings, and metadata belonging to or generated on behalf of a single Controller within the Platform.
2.1 The parties acknowledge and agree that the Controller retains exclusive determination over the purposes and means of Processing, including but not limited to: (a) the selection of Agentic Workflow parameters; (b) the designation of Communication Channels for deployment; (c) the scope of calendar resources made accessible via delegated authorisation; (d) the content of system prompts and operational directives supplied to Agentic Workflows; and (e) the retention period applicable to Tenant Corpora categories.
2.2 The Processor shall Process Personal Data exclusively on the documented instructions of the Controller, unless required to do otherwise by applicable Union or Member State law. The Processor shall immediately inform the Controller if, in its opinion, an instruction infringes applicable data protection legislation.
2.3 The Processor is hereby authorised to engage sub-processors to fulfil specific processing activities. The current sub-processor schedule comprises: (a) cloud infrastructure providers for compute and storage; (b) inference API providers for large language model invocations under contractual prohibitions on training-data absorption; (c) content delivery network operators for edge-cached static assets. The Processor shall provide thirty (30) days' prior notice of any sub-processor addition or replacement, during which period the Controller may object on reasonable grounds related to data protection.
2.4 Liability allocation shall follow causation: each party shall be liable for damages caused by processing that infringes the GDPR or applicable data protection legislation only where that party failed to meet its respective obligations. The Processor's aggregate liability under this DPA shall be subject to the liability cap set forth in the Master Subscription Agreement.
3.1 The Platform implements logical partitioning of Tenant Corpora such that no cross-tenant data access, traversal, or inference is possible through standard Platform operations. Access to Tenant Corpora is governed by a row-level and collection-level authorisation enforcement layer that evaluates each operation against the authenticated principal's tenancy scope prior to any data plane execution.
3.2 Non-commingling obligations apply at every layer of the processing stack: (a) inference context windows are scoped to a single tenant session; (b) vector index corpora are partitioned by tenancy identifier with retrieval restricted to the originating tenant; (c) durable persistence layer collections are keyed by tenant identifier with queries enforcing tenant-scoped filters at the application boundary.
3.3 The Processor shall not access Tenant Corpora for its own purposes, including but not limited to model training, product improvement, analytics, or benchmarking, unless expressly authorised in writing by the Controller. This prohibition survives termination of the Master Subscription Agreement.
4.1 Agentic Workflows may, in the ordinary course of Platform operation, produce outputs that constitute automated decision-making pursuant to Article 22 GDPR, including but not limited to: (a) appointment scheduling determinations based on calendar availability assessments; (b) lead qualification and routing decisions based on natural language classification; (c) response prioritisation based on conversational context analysis.
4.2 The Controller acknowledges that Agentic Workflows incorporate stochastic inference components whose outputs are non-deterministic by nature. The Processor makes no representation that any particular Agentic Workflow output will be repeated upon re-generation, nor that outputs will be free of hallucinated or factually inaccurate content.
4.3 Human-in-the-loop override mechanisms are available at the following junctures: (a) the Controller may pre-define approval workflows for specified decision categories; (b) any Agentic Workflow output may be overridden, edited, or discarded by an authorised human operator through the administrative interface; (c) the Controller may designate specific processing actions that require human ratification prior to execution.
4.4 Inference pipeline data retention parameters are as follows: (a) input prompts and output completions transmitted to third-party inference providers are logged with full content retention for a period not to exceed ninety (90) days, unless a shorter period is configured by the Controller; (b) inference telemetry (token counts, latency, model identifier) is retained for one hundred eighty (180) days for operational monitoring purposes; (c) no inference data is used for fine-tuning, model distillation, or any form of training data augmentation unless the Controller has executed a separate written agreement expressly authorising such use.
5.1 Session-scoped memory constitutes Ephemeral Context and is retained in volatile inference state exclusively for the duration of the immediate Agentic Workflow invocation. Upon completion or timeout of the invocation, Ephemeral Context is irretrievably discarded and cannot be recovered.
5.2 Transient context window residency is limited to the processing lifecycle of a single request-response cycle. No Ephemeral Context is written to any durable persistence layer unless the Controller has explicitly configured the Platform to capture conversation history for continuity purposes.
5.3 Where the Controller elects to enable durable session persistence, the following distinctions apply: (a) conversation history is committed to the durable persistence layer as structured message objects with full content retention; (b) vectorised representations of conversation context may be generated and stored in tenant-partitioned vector index corpora for retrieval-augmented inference; (c) Data Subject rights under Articles 15 through 22 GDPR apply differently to persistent artefacts versus Ephemeral Context, as the latter cannot, by definition, be retrieved, rectified, or erased.
5.4 The Processor shall, upon Controller request, provide a mapping of which processing artefacts are volatile versus persistent to facilitate the Controller's data mapping obligations under applicable data protection legislation.
6.1 The Platform integrates with third-party messaging protocols through OAuth 2.0 delegated authorisation frameworks. Credentials (access tokens, refresh tokens, session identifiers) are custodied within the Platform's secure credential management subsystem, encrypted at rest and in transit.
6.2 The Controller bears sole responsibility for: (a) obtaining all necessary consents and authorisations from Data Subjects for communication via integrated Channels; (b) ensuring that Channel-specific terms of service and API usage policies are complied with; (c) managing the lifecycle of OAuth consent grants with each Channel provider.
6.3 Credential rotation shall occur: (a) automatically upon expiry of the underlying OAuth token, with the Platform initiating the refresh token flow; (b) upon manual revocation initiated by the Controller through the administrative interface; (c) immediately upon notification from the Channel provider of a security incident affecting the credential.
6.4 Revocation propagation timelines: (a) Platform-level credential revocation takes effect within fifteen (15) minutes across all active sessions; (b) Channel provider-side revocation is subject to the provider's own propagation schedule and is outside the Processor's control; (c) the Processor shall notify the Controller within twenty-four (24) hours of becoming aware that a Channel provider has revoked or invalidated a credential.
7.1 The lawful basis for Processing calendar corpus data is the Controller's legitimate interest in automated scheduling, exercised through delegated OAuth authorisation granted by the Controller or its authorised users. The Platform processes calendar data strictly within the scope of the authorised OAuth grant.
7.2 Calendar data accessed via delegated authorisation is processed for the following limited purposes: (a) availability assessment through temporal occupancy evaluation; (b) event creation to effectuate scheduling requests initiated through Agentic Workflows; (c) synchronisation status verification to maintain connection integrity.
7.3 Retention limits on scheduling telemetry: (a) event metadata (summary, start time, end time, description) is retained as part of the Agentic Workflow conversation history in accordance with the Controller's configured retention policy; (b) raw calendar event lists fetched during availability assessment are not cached beyond the immediate request-response cycle; (c) aggregated scheduling metrics (booking volume, average lead time, cancellation rate) may be retained for Platform analytics purposes in de-identified form only.
7.4 Secondary use of appointment metadata is expressly prohibited. The Processor shall not: (a) mine, analyse, or derive insights from event summaries or descriptions; (b) correlate appointment data across tenants; (c) use scheduling patterns for any purpose not directly related to the provision of the Platform's core functionality to the Controller.
8.1 The Platform maintains an immutable audit trail capturing the following categories of events: (a) administrative actions performed through the management interface; (b) Agentic Workflow invocations and their outcomes; (c) OAuth token lifecycle events; (d) data access events at the persistence layer; (e) configuration changes affecting processing behaviour.
8.2 Audit logs are retained for a minimum period of twelve (12) months and a maximum period of thirty-six (36) months, after which they are irreversibly purged. Logs are append-only with cryptographic integrity verification to detect retroactive modification.
8.3 Access to audit log corpora is restricted to: (a) Platform administrators with a demonstrated need-to-know for operational security purposes; (b) the Controller's authorised representatives for their own Tenant Corpora audit logs only; (c) authorised supervisory authorities exercising their lawful investigative powers.
8.4 Telemetry corpora (performance metrics, error rates, usage statistics) are retained in a separate analytics environment from production data. Cross-environment exfiltration of telemetry data outside the designated processing environment is prohibited. Where telemetry data containing Personal Data is required for security analysis, it shall be de-identified prior to transfer.
9.1 Request intake procedures: Data Subjects wishing to exercise their rights under Articles 15 through 22 GDPR or equivalent provisions under applicable data protection legislation shall submit their request to the Controller in the first instance. The Controller may forward verified requests to the Processor at [email protected]. The Processor shall not respond directly to Data Subject requests unless expressly authorised by the Controller.
9.2 Verification obligations: the Processor shall assist the Controller in verifying the identity of the requesting Data Subject to a standard of reasonable certainty commensurate with the sensitivity of the Personal Data requested. The Processor reserves the right to request additional information where the initial verification evidence is insufficient.
9.3 Fulfilment SLAs: (a) access requests (Article 15) — response within thirty (30) calendar days of verified receipt; (b) rectification requests (Article 16) — completion within fifteen (15) calendar days; (c) erasure requests (Article 17) — completion within thirty (30) calendar days; (d) portability requests (Article 20) — response within thirty (30) calendar days. These SLAs may be extended by up to sixty (60) days where the request is complex or where multiple requests have been received from the same Data Subject.
9.4 Technical mechanisms for erasure propagation: upon fulfilment of an erasure request, the Processor shall: (a) delete the primary record from the durable persistence layer; (b) request deletion from backup snapshots on the next rotation cycle but in any event within ninety (90) days; (c) purge corresponding vector embeddings from tenant-partitioned index corpora; (d) clear any cached representations of the erased data from all inference cache layers; (e) confirm in writing that each of the foregoing actions has been completed. The Processor shall provide a certificate of erasure upon request.
10.1 Where Processing involves the transfer of Personal Data from the European Economic Area, the United Kingdom, Switzerland, or any other jurisdiction with cross-border transfer restrictions, the parties shall rely on: (a) an adequacy decision pursuant to Article 45 GDPR where the receiving jurisdiction has been determined to provide adequate protection; (b) Standard Contractual Clauses adopted by the European Commission pursuant to Article 46(2)(c) GDPR, which are hereby incorporated by reference; (c) binding corporate rules, where applicable; or (d) derogations for specific situations pursuant to Article 49 GDPR where no other transfer mechanism is available.
10.2 The Processor shall, prior to any transfer to a sub-processor located in a third country without an adequacy decision, ensure that the sub-processor is bound by Standard Contractual Clauses or an equivalent transfer mechanism recognised under applicable law.
10.3 Transfer Impact Assessments: the Processor shall, upon reasonable request, provide the Controller with information necessary to conduct a Transfer Impact Assessment for high-risk jurisdictions, including: (a) a description of the legal framework governing public authority access to transferred data in the receiving jurisdiction; (b) supplementary technical safeguards implemented to protect transferred data; (c) the Processor's assessment of whether the transfer ensures an essentially equivalent level of protection.
10.4 Where a transfer mechanism is invalidated or rendered inadequate by a change in law or supervisory authority ruling, the Processor shall immediately suspend the affected transfers and notify the Controller to agree on alternative transfer mechanisms.
11.1 Breach classification taxonomy: (a) Level 1 (Low Severity) — unauthorised access to non-Personal Data or metadata where no Data Subject rights have been materially affected; (b) Level 2 (Medium Severity) — unauthorised access to Personal Data affecting fewer than one thousand (1,000) Data Subjects, or temporary loss of availability of Personal Data; (c) Level 3 (High Severity) — unauthorised access to special category data, or Personal Data affecting more than one thousand (1,000) Data Subjects, or permanent loss of availability of Personal Data; (d) Level 4 (Critical Severity) — systemic breach affecting multiple tenants, or exfiltration of authentication credentials, or any breach reasonably likely to result in significant reputational or financial harm.
11.2 Notification trigger thresholds: (a) Level 1 — notification to Controller within seventy-two (72) hours of confirmation; (b) Level 2 — notification to Controller within twenty-four (24) hours; (c) Level 3 — notification to Controller within twelve (12) hours; (d) Level 4 — notification to Controller within four (4) hours, with hourly updates until containment.
11.3 Supervisory authority reporting (Article 33 GDPR): the Processor shall provide the Controller with all information necessary to notify the competent supervisory authority within seventy-two (72) hours of becoming aware of a Personal Data Breach. The Processor shall assist the Controller in preparing the notification, including: (a) a description of the nature of the breach; (b) the categories and approximate number of Data Subjects concerned; (c) the likely consequences; (d) measures taken or proposed to address the breach.
11.4 Data Subject notification (Article 34 GDPR): where the breach is likely to result in a high risk to the rights and freedoms of Data Subjects, the Processor shall assist the Controller in communicating the breach to affected Data Subjects without undue delay, including: (a) the nature of the breach; (b) recommendations for mitigating potential adverse effects; (c) contact details for the Processor's security incident response team.
12.1 Retention schedule matrix by data category: (a) Conversation history — retained per Controller-configured policy, default one hundred eighty (180) days, maximum three hundred sixty-five (365) days; (b) Vector embeddings — retained for the duration of the corresponding conversation history plus thirty (30) days for index rebuild operations; (c) Audit logs — retained for twelve (12) months minimum, thirty-six (36) months maximum; (d) OAuth credential artefacts — retained until credential revocation or six (6) months post-tenant account termination; (e) Inference telemetry — retained for ninety (90) days.
12.2 Automated purge trigger conditions: (a) expiry of configured retention period — purge executed within twenty-four (24) hours of schedule; (b) tenant account termination — purge initiated within seventy-two (72) hours; (c) data subject erasure request — purge initiated within twenty-four (24) hours of verification; (d) storage quota threshold — oldest data in excess of quota purged on a first-expiry-first-purge basis.
12.3 Backup exclusion procedures: backup snapshots shall include Tenant Corpora for business continuity purposes but are subject to the following exclusions: (a) Ephemeral Context is not included in any backup; (b) inference cache layers are not included in any backup; (c) OAuth credential artefacts are excluded from backup where technically feasible; (d) any data category that the Controller has designated for exclusion in writing.
12.4 Post-termination data return or destruction: within thirty (30) days of Master Subscription Agreement termination, the Controller may request: (a) export of Tenant Corpora in a commonly used, machine-readable format; or (b) certified destruction of all Tenant Corpora. If the Controller does not elect an option within the thirty-day period, the Processor shall initiate automated destruction. The Processor shall provide a certificate of destruction confirming that all Tenant Corpora, including all backup copies, have been irreversibly purged within a further ninety (90) days to accommodate backup rotation cycles.
13.1 Cryptographic controls: the Platform implements encryption for data at rest and in transit using industry-standard cryptographic primitives. Encryption keys are managed through a dedicated key management subsystem with distinct key hierarchies for production, staging, and analytics environments. Key material is rotated on a periodic schedule not exceeding twelve (12) months, and upon any indication of key compromise.
13.2 Access management: production access is governed by a role-based access control framework with the following principles: (a) least privilege — principals are granted the minimum permissions necessary to perform their function; (b) just-in-time access — privileged access is time-bound and requires approval; (c) multi-factor authentication is enforced for all production access; (d) access reviews are conducted quarterly with revocation of stale or excessive entitlements.
13.3 Penetration testing: the Platform undergoes independent third-party penetration testing at least annually, and upon any material change to the production architecture. Testing covers: (a) web application vulnerabilities; (b) API security; (c) authentication and authorisation mechanisms; (d) tenant isolation boundaries; (e) infrastructure configuration. A summary of the latest penetration test results is available to the Controller upon execution of a mutual non-disclosure agreement.
13.4 Vulnerability disclosure: the Processor maintains a vulnerability disclosure programme through which external researchers may report potential security issues. The Processor commits to: (a) acknowledging receipt of vulnerability reports within five (5) business days; (b) providing regular status updates on remediation progress; (c) remediating critical-severity vulnerabilities within thirty (30) days of verification; (d) publishing security advisories for vulnerabilities affecting tenant data protection.
14.1 Syrex Tech operates a dual-function delivery model comprising: (a) the Platform, being the multi-tenant SaaS agentic AI system governed by the Master Subscription Agreement; and (b) Syrex Agency Services, being bespoke software development, custom agent engineering, systems integration, and consulting engagements governed by separate Statement of Work instruments.
14.2 Intellectual Property Vesting: All intellectual property rights in and to any deliverables, work product, source code, object code, documentation, designs, algorithms, models, configurations, prompts, tool definitions, workflow orchestrations, and any other artefacts created by Syrex Tech in the course of performing Agency Services shall vest exclusively in Syrex Tech unless a separate written agreement executed by both parties expressly provides for assignment of such rights to the Client.
14.3 No Implied Assignment: In the absence of a duly executed written agreement containing an express intellectual property assignment clause, no transfer of ownership, licence, or other right in any Syrex Tech intellectual property shall be implied by virtue of payment, delivery, access, or any other conduct. Any purported assignment by conduct, estoppel, or oral agreement is expressly excluded and shall be void ab initio.
14.4 Pre-Existing Materials: Syrex Tech retains all right, title, and interest in and to its pre-existing materials, including but not limited to: the Platform architecture, inference pipelines, orchestration frameworks, prompt libraries, tool schemas, vector index methodologies, authentication subsystems, and any derivative works thereof. No licence to such pre-existing materials is granted except to the extent necessary for the Client to use the delivered Agency Services deliverables for their intended purpose.
14.5 Moral Rights and Waiver: To the maximum extent permitted by applicable law, Syrex Tech waives any moral rights in deliverables created for Agency Services engagements. Where moral rights cannot be waived, the Client grants Syrex Tech a perpetual, irrevocable, worldwide, royalty-free licence to use, modify, and distribute such deliverables for portfolio, marketing, and reference purposes, unless a written agreement expressly restricts such use.
14.6 Confidentiality of Engagement: The existence, terms, and deliverables of any Agency Services engagement are confidential. Syrex Tech shall not disclose the Client's identity or engagement particulars to any third party without prior written consent, except: (a) as required by law; (b) to enforce rights under this Agreement; (c) for portfolio and marketing purposes on an anonymised basis.
15.1 Where Syrex Tech provides voice-enabled Agentic Workflows, audio streams are processed in accordance with the following framework: (a) real-time audio transmission is handled through peer-to-peer or relayed infrastructure with encryption in transit; (b) audio streams are transcribed into text representations by inference pipelines for the purpose of generating Agentic Workflow responses; (c) raw audio packets are ephemeral by default and are irretrievably discarded immediately following transcription unless the Controller has expressly elected and configured compliance-grade logging for regulatory retention purposes.
15.2 Where compliance logging is enabled by the Controller: (a) audio recordings are retained in encrypted form for the Controller's configured retention period; (b) access to retained audio recordings is restricted to the Controller's authorised representatives through the administrative interface; (c) Syrex Tech personnel do not access retained audio recordings except to fulfil technical support requests or legal obligations.
15.3 The Controller represents and warrants that it has obtained all necessary consents from Data Subjects for the recording, transcription, and processing of voice communications through the Platform, including any jurisdiction-specific requirements for party consent to call recording.
16.1 The Platform deploys minimal tracking technologies strictly limited to: (a) authentication session management; (b) edge-node performance telemetry; (c) security monitoring and threat detection. No tracking technology is used for advertising, audience profiling, behavioural analytics, or any commercial data monetisation purpose.
16.2 Telemetry data collected at the edge comprises aggregate performance metrics and does not include Personal Data unless required for security incident investigation. Where Personal Data is temporarily collected for investigative purposes, it shall be de-identified within thirty (30) days of incident closure and purged within ninety (90) days.
16.3 The Platform does not sell, license, or otherwise transfer Personal Data to any advertising network, data broker, or similar third party. The Controller is deploying an enterprise processing environment, not participating in a consumer data ecosystem.
17.1 This DPA shall be governed by and construed in accordance with the laws of the jurisdiction specified in the Master Subscription Agreement, without regard to conflict of law principles.
17.2 Any dispute arising out of or in connection with this DPA shall be resolved through the dispute resolution mechanism set forth in the Master Subscription Agreement.
17.3 In the event of any inconsistency between this DPA and the Master Subscription Agreement, the DPA shall prevail with respect to data protection matters.
18.1 Any communication required or permitted under this DPA relating to data protection matters shall be addressed to the Data Protection Officer at [email protected].
18.2 Notifications of supervisory authority orders, data subject requests, or security incidents shall reference the Controller's tenant identifier and the relevant Article of this DPA.
19.1 Google API Integration: Syrex Tech's use of information received from Google APIs (including Google Calendar API) adheres to the Google API Services User Data Policy, including the Limited Use requirements.
19.2 Limited Use:Syrex Tech's access to Google user data (including Google Calendar data) is limited to the following purposes: (a) providing and improving the features of the Syrex platform that are visible to the user; (b) enabling the AI scheduling agent to read and create calendar events on behalf of the authenticated user. Google user data is not used for serving advertisements, not transferred to third parties except as necessary to provide the service, not used or transferred for purposes unrelated to improving user-facing features, and not used or transferred to determine creditworthiness or for lending purposes.
19.3 Calendar Data Access: Google Calendar access is granted exclusively through explicit user consent via an incremental OAuth 2.0 authorization flow. This is separate from the primary account login. Users may revoke this access at any time through their Google Account Permissions page or through the Syrex platform settings. Revoking access will immediately prevent the AI agent from accessing or modifying calendar events.
19.4 No Unauthorized Use: Syrex Tech does not use Google user data to train machine learning models, does not share, sell, or license Google user data to any third party, and does not retain Google Calendar data beyond what is necessary to execute a specific scheduling instruction requested by the user.
This document supersedes all prior privacy policies and data processing disclosures published by the Processor. It shall be reviewed and updated at least annually, or upon material changes to Platform architecture or applicable law, whichever occurs first.