airlock
Home
Product▾
OverviewIntegrationsCompare alternativesDocumentation
PricingBlog
Free tools▾
AI policy generatorAI adoption starter kit
LoginStart free
  • Home
  • Product
    • Overview
    • Integrations
    • Compare alternatives
    • Documentation
  • Pricing
  • Blog
  • Free tools
    • AI policy generator
    • AI adoption starter kit
LoginStart free →
Legal

Data Processing Agreement.

Last updated: August 26, 2026

On this page

    This Data Processing Agreement ("DPA") is entered into between Airlock BV, having its seat at Colmarstraat 38, 9100 Sint-Niklaas, Belgium, registered with the Crossroad Bank of Enterprises under number 1037836652 (the "Company", "Processor"), and the customer using the airlock Service (the "User", "Controller"). It forms an integral part of the Terms & Conditions or any signed License and Subscription Agreement between the parties (jointly, the "Agreement").

    Capitalized terms not defined in this DPA have the meaning given in the Agreement or, if applicable, in the GDPR.

    1. Processing activities

    1.1 Subject matter

    The Company provides a digital platform that acts as a secure proxy and governance layer between AI agents and business applications and APIs, branded "airlock", providing centralized credential management, policy enforcement, audit logging, human-in-the-loop approval workflows, and centralized skill management and distribution for AI agent interactions (the "Platform"). The User uses the Platform as a supporting digital tool for its business processes and workflows.

    The Company acts as a Processor in relation to any Personal Data that is submitted through the Platform by the User (the Controller) or its Authorized Representatives, or that is derived from the User's business applications.

    When processing Personal Data pursuant to the Agreement, the parties shall comply with the GDPR and any applicable codes of conduct, Standard Contractual Clauses, and other related regulations.

    1.2 Overview of processing activities

    The Processor will process Personal Data for the purposes of hosting, transmission, consultation, structuring, modification, retrieval, alignment, restriction, erasure, and other operations performed on Personal Data by automated means through the Platform. The processing activities are more specifically set forth in Annex A to this DPA.

    Processing carried out by the Company for its own purposes (e.g. invoicing, recovery, complaints handling, defence of legal claims, and the derived data described in Clause 7.4) falls outside the scope of this DPA and is governed by the Privacy Policy.

    1.3 Duration

    The Company may conduct the processing activities under this DPA for the entire term of the Agreement, plus a 60-day post-termination export window, any retention period imposed on the Company by mandatory law, and the audit-archive retention lock described in Clause 6.2, which is a security control rather than a legal obligation and is stated there for that reason.

    2. Undertakings of the Processor

    • Process Personal Data only on documented instructions from the Controller (including with regard to transfers to a third country or international organization), unless required by Union or Member State law to which the Processor is subject. The Controller's instructions are set out in the Agreement, the Privacy Policy, the configuration the Controller maintains in the Control Room, and any further written instructions.
    • Promptly inform the Controller if, in its opinion, any instruction infringes the GDPR or other applicable data protection provisions.
    • Use Personal Data only for the proper execution of the Agreement.
    • Not disclose Personal Data to third parties without the Controller's prior written approval, except as permitted by this DPA or required by law.
    • Ensure that persons authorized to process the Personal Data are committed to confidentiality by agreement or are under an appropriate statutory obligation of confidentiality.
    • Implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk (Clause 3 of this DPA), and provide a detailed written description of those measures upon request.
    • Engage sub-processors only as described in Clause 4 and impose substantially the same data protection obligations on them.
    • Assist the Controller with appropriate technical and organizational measures, insofar as possible, in responding to data subject rights requests and in meeting the Controller's other obligations under the GDPR (including Articles 32 to 36).
    • Take into account the principles of data protection by design and by default when processing Personal Data.
    • Notify the Controller of any Personal Data Breach without undue delay and in any event within 48 hours of becoming aware of the breach, and implement any reasonable instructions in respect of the breach.
    • Not process Personal Data outside the EEA without the Controller's written consent or unless stated otherwise in this DPA, and only subject to the safeguards required under the GDPR.
    • Not keep Personal Data longer than required for the performance of the Agreement, unless another storage period is set forth in the Agreement, instructed by the Controller, or otherwise applies pursuant to applicable law. The retention period applicable to each category of data is set out in Clause 6.1 and Annex B.
    • Delete or return (at the Controller's choice) all Personal Data after the end of the Agreement, in accordance with Clause 6, and delete existing copies unless applicable law requires storage. The Processor may retain aggregated, anonymized, or pseudonymized data as derived data of the Company.
    • Make available all information necessary to demonstrate compliance with this DPA and contribute to audits, including inspections, conducted by the Controller or an auditor it mandates, on reasonable prior notice, during business hours, and subject to appropriate confidentiality obligations.

    3. Technical and organizational measures

    The Processor implements the following measures, described in more detail in the Company's information security documentation, available to the Controller on request and subject to confidentiality:

    • Confidentiality: encryption of credentials and sensitive fields at rest with AES-256-GCM under AWS KMS envelope encryption; TLS 1.2+ in transit; access controls based on least-privilege and role-based access; platform secrets stored as KMS-encrypted SecureString parameters in AWS Systems Manager Parameter Store, read at runtime under per-function IAM scopes and recorded in AWS CloudTrail.
    • Infrastructure: serverless compute (AWS Lambda) and managed databases with encryption at rest, hosted on AWS in the EU (Frankfurt, eu-central-1); runtime application security via Aikido Zen Firewall. Customer Data is stored at rest exclusively in eu-central-1, subject to the qualifications described in Clause 4.1.
    • Isolation: multi-tenant architecture with logical separation of each organization's data, enforced at the application and database layer.
    • Integrity: tamper-evident audit logs; signed deployment artifacts; code review and CI controls; audit trail of staff access to tenant environments.
    • Data masking: credentials decrypted only at the moment of API execution and never written to a log; secret-bearing fields stripped, and request and response bodies redacted and truncated, before they are written to the audit trail. This redaction applies to the audit trail. The separate analytics record described in Annex A, entry 5 retains the full request and response bodies of tool calls; the Controller should read that entry together with this measure.
    • Availability: automated backups; AWS multi-AZ deployment; planned maintenance announced in advance.

    4. Sub-processors and international transfers

    4.1 Hosting location

    Customer Data processed under this DPA is stored at rest in the EU, in the AWS Frankfurt region (eu-central-1). Three qualifications apply to that statement, and the Processor states them rather than leaving the residency claim unqualified:

    • Content delivery uses a global edge network. The Platform's web interfaces are served through Amazon CloudFront, which terminates TLS and serves cached content from edge locations worldwide, including outside the EEA. Requests carrying Personal Data traverse the edge location nearest the requesting user before reaching the origin in eu-central-1. Amazon Web Services is an authorized sub-processor for this activity under Clause 4.2, and the transfer is covered by the safeguards described there.
    • Analytics events reach PostHog through a global-edge reverse proxy. The product-analytics events described in Clause 4.2 that originate in the user's browser are not sent to PostHog's EU ingest endpoint directly. They are sent to a PostHog-operated managed reverse proxy on a Company-branded hostname, which accepts the request at the edge location nearest the signed-in user — including outside the EEA — before forwarding it to PostHog's EU project. The identifiers listed in Clause 4.2 therefore traverse that edge path before coming to rest in the EU. This is a different path from the Amazon CloudFront delivery described above, and is stated separately for that reason.
    • TLS certificates are issued in us-east-1. AWS requires certificates for CloudFront distributions and for Amazon Cognito custom domains to be issued in the us-east-1 region. The Processor therefore holds certificates in that region. Certificates contain domain names and public keys only; they carry no Personal Data, and no Customer Data is stored or processed in us-east-1 as a result.

    4.2 Authorized sub-processors

    The Controller grants general authorization for the use of the following sub-processors:

    • Amazon Web Services EMEA SARL (Luxembourg; EU regions, with global edge delivery as described in Clause 4.1): hosting, database, authentication (Cognito), serverless compute, transactional email (Amazon SES), content delivery (CloudFront), and model inference via AWS Bedrock. Bedrock is used for three purposes, all in EU regions: embedding models used to index content the Controller connects for search; generative inference on the default model route described in Clause 4.5, which receives the content of the Controller's requests; and automated security scanning of skill content the Controller imports, which sends the body and attachments of that content to a model for assessment.
    • Aikido Security NV (Belgium): runtime application security (Zen Firewall).
    • PostHog Inc. (EU Cloud, eu.i.posthog.com, data hosted in the EU): product analytics and backend error telemetry. This processing is not anonymized. When an Authorized Representative is signed in, the Platform transmits that person's user identifier, email address, first name, last name, role, organization identifier and organization name, and associates their subsequent product-usage events with those identifiers. Earlier versions of this DPA described this activity as anonymized analytics; that description was inaccurate and has been corrected.

      Separately from the browser analytics above, when a server-side request fails the Platform sends the resulting error record to PostHog, carrying the acting user identifier, organization identifier, request identifier, request path and method, and the handler or tool involved. That record follows a different path: it is sent from the Processor's backend directly to PostHog's EU endpoint and does not traverse the reverse proxy described in Clause 4.1.
    • Slack Technologies (a Salesforce company; United States): internal operational notifications. The Platform posts two kinds of message to the Processor's own internal Slack workspace. Account-lifecycle alerts (free-trial warnings and expiries) carry the organization's name, slug, identifier and member count, and no user-account fields. Integration-interest alerts, sent the first time an Authorized Representative clicks an integration the Platform does not yet support, carry that representative's email address and user identifier alongside the organization identifier and the integration name. An earlier version of this Clause stated that these messages carry no representative's email address or account identifier; that was inaccurate for the integration-interest path and has been corrected. Neither kind of message carries Customer Data routed through the Platform. Both are transfers of Personal Data under Clause 4.3.

    4.3 Transfers outside the EEA

    Amazon Web Services EMEA SARL and PostHog Inc. process Personal Data under this DPA in the EU, subject to Clause 4.1. Slack Technologies processes the limited data described in Clause 4.2 in the United States. Where a sub-processor processes Personal Data outside the EEA, the Processor relies on the Standard Contractual Clauses adopted by the European Commission and on supplementary measures including encryption in transit and data minimization. Details of the safeguards in place for any listed sub-processor are available to the Controller on request.

    4.4 Changes to sub-processors

    The Processor shall inform the Controller of any intended addition or replacement of sub-processors with at least 15 days prior written notice. The Controller may object on reasonable data-protection grounds within that period. Where the Processor engages a sub-processor for processing activities on behalf of the Controller, it imposes substantially the same data protection obligations on that sub-processor.

    Note on the sub-processors added to this list on August 25, 2026. Slack Technologies was already receiving the data described in Clause 4.2 before that date; listing it is a correction of an incomplete disclosure, not a new engagement, and the 15-day notice period in this Clause is therefore not triggered by the listing itself. The Processor nevertheless extends the objection right: a Controller may object to any sub-processor listed for the first time on August 25, 2026 on reasonable data-protection grounds, on the same terms as for a newly engaged sub-processor, by writing to the address in the Contact section. This date is fixed and does not move when this DPA is next revised.

    4.5 Customer-configured model routing

    The Platform can route requests to language models over more than one path. By default it uses AWS Bedrock in an EU region, and no configuration by the Controller is required to keep it there.

    A Controller may additionally supply its own credential for a third-party model aggregator (currently OpenRouter, which is hosted in the United States). Where the Controller does so, the Platform will route requests for the models served over that path to that provider, and the content of those requests — which may include Personal Data drawn from the Controller's connected systems — leaves the EEA. The Processor's position is that this is a transfer directed by the Controller, not the Processor's engagement of a sub-processor: the route exists only because the Controller supplied the credential, that act is the Controller's documented instruction under Clause 2, and the Controller is the party in a contractual relationship with the provider. Such a provider is accordingly not listed in Clause 4.2, and Clause 4.4 does not apply to it.

    Two consequences follow, and the Processor states them plainly. First, the Controller is responsible for the Chapter V GDPR safeguards covering that transfer and for the provider's terms, including whether the provider logs or trains on the content of requests. Second, the Platform records a residency attribute for each model route and surfaces it to the Controller, but that attribute is reported, not enforced: it does not prevent a request from being routed outside the EEA. A Controller that requires EU-only model processing should not configure a non-EU credential. The Processor does not enable any such route on the Controller's behalf.

    4.6 Connected integrations are not sub-processors

    The User's use of its own business applications, tools, MCP servers, or other third-party services through the Platform does not constitute the engagement of those providers as the Company's (sub)processors. They are involved at the User's sole and exclusive responsibility, and the Company is not responsible for their availability, accuracy, security, or behavior.

    5. Data subject rights

    Taking into account the nature of the processing, the Processor shall assist the Controller by appropriate technical and organizational measures, insofar as possible, for the fulfilment of the Controller's obligation to respond to requests for exercising the data subject's rights under Chapter III GDPR, including the right of access (Article 15), the right to rectification (Article 16), the right to erasure / right to be forgotten (Article 17), the right to restriction of processing (Article 18), the right to data portability (Article 20), and the right to object (Article 21).

    The Processor shall forward to the Controller, without undue delay, any data subject request received directly by the Processor and shall not respond to such requests without the Controller's prior written authorization, except to acknowledge receipt.

    6. Retention, deletion and return

    6.1 Retention periods

    Retention is set per category of data rather than by a single period. Annex B states the period that applies to each category.

    Annex B governs. For the categories generated by the Platform's own logging — the audit trail, its archive copy, and infrastructure logs — the periods in Annex B are reconciled against the Company's internal Logging Policy, which records each period together with the reason it is set where it is and is available to the Controller on request, subject to confidentiality. That policy is an internal operational document: it is not incorporated into this DPA, and a change to it does not alter the Controller's rights under this Clause. Where the two differ, Annex B prevails and the Company will reconcile the difference.

    6.2 Deletion and return

    On termination of the Agreement (and ultimately 60 days after termination), the Processor shall return to the Controller all Personal Data processed on its behalf, in a structured, commonly used, and machine-readable format, or securely delete all Personal Data, and confirm such deletion in writing on the Controller's request.

    The Processor may retain aggregated, anonymized, or pseudonymized derived data and any copy of Personal Data whose retention is required by law (such as billing records or compliance logs). On Account deletion, the Processor's workflow ensures the anonymization of the profile.

    One stated exception to the 60-day deadline. The tamper-resistant audit archive described in Annex B is held in write-once storage under a retention lock of at least one year, applied when each object is written. The purpose of that lock is to make the archive resistant to deletion by a privileged administrator, which is what gives it its evidential value. Where termination falls inside that window, archived audit records are therefore not deleted at day 60. No other category is subject to this exception, and it does not extend to Customer Data outside the audit archive.

    The Processor states two properties of that exception plainly rather than overstating it. First, the lock is enforced in governance mode: no Processor role is granted the permission required to override it, so it holds against the Processor's own administrators in normal operation, but it is a deliberately recoverable control rather than an absolute technical impossibility, and a break-glass override by a sufficiently privileged account principal remains available as an audited action. Second, no automatic expiry is configured for archived objects once their lock ends; they are not deleted by the passage of time. The Processor will delete archived records relating to the Controller on written request once their retention lock has expired, and will confirm that deletion in writing.

    7. General disclaimers

    7.1 Special category data (Art. 9 GDPR)

    The Platform is an infrastructure-level service. Whether special category data flows through the Platform depends on the User's deployment (the AI agents, business applications, and APIs the User connects). The Controller must determine, prior to deployment, whether such categories are involved and whether an appropriate exception under Art. 9(2) GDPR applies and is documented. If special category data, or criminal-offence data (Art. 10 GDPR), is processed, the parties shall agree on the additional safeguards required under Art. 32 GDPR.

    To make that assessment possible rather than abstract, the Processor identifies where such data is most likely to come to rest: the full tool call payloads described in Annex A, entry 5, which retain the complete request and response bodies exchanged with the Controller's own systems. The Controller is best placed to know what those systems hold.

    7.2 DPIA (Art. 35 GDPR)

    Use of the Platform may, depending on the deployment context, meet two or more of the EDPB criteria for a likely high-risk processing operation (in particular: innovative use of technology, AI agents acting on behalf of the Controller, systematic monitoring, automated decision-making, large-scale processing). The Controller is responsible for assessing whether a DPIA is required and, where applicable, conducting one before processing begins. The Company shall provide reasonable assistance under Art. 28(3)(f) GDPR.

    7.3 Automated decision-making and AI Act

    Where requests routed through the Platform result in automated decisions producing legal or similarly significant effects on individuals, the Controller shall implement the safeguards required by Art. 22 GDPR. If the AI agents qualify as a high-risk AI system under Regulation (EU) 2024/1689 (the AI Act), the Controller shall additionally consider the Fundamental Rights Impact Assessment (FRIA) and other transparency obligations applicable to deployers. This is the sole responsibility of the Controller.

    7.4 Derived data

    Derived data generated by the Platform (such as aggregated usage analytics and model performance metrics) pertains to the Company. To the extent such derived data, after de-identification, no longer constitutes Personal Data, it falls outside the scope of this DPA. To the extent it remains Personal Data, it is processed by the Company on the basis of its own legal basis as Controller in accordance with the Privacy Policy.

    Annex A. Processing purposes and categories

    The following table sets out the processing activities under this DPA.

    Processing purposeData subjects / categories of personal data
    1. Hosting and making available Personal Data inserted in or transmitted through the Platform. Storing Customer Data on the Company's infrastructure and rendering it accessible to the User and its Authorized Representatives.Authorized Representatives; the User's customers, suppliers, agents and other persons involved in the User's business; end-users whose data is routed through the User's AI agents. Identification data (name, email, function/role); account identifiers; any content data inserted in Requests; any other Personal Data the User chooses to route through the Platform.
    2. Operating the secure proxy and governance layer between AI agents and business applications/APIs. Brokering, transforming, and forwarding requests/responses between the User's AI agents and its business applications/APIs.Persons whose data is contained in the User's business applications/APIs and is accessed by, or communicated to, the User's AI agents through the Platform. Any Personal Data routed through the proxy on the User's instructions, including identification, contact, and content data.
    3. Centralized credential management. Storing, transmitting, validating, and rotating authentication credentials for the User's Authorized Representatives and User Accounts.Authorized Representatives; persons authorized on the User's connected systems. Identification data; authentication credentials and secrets (usernames, hashed passwords, API keys, tokens); IP and device information used during authentication.
    4. Policy enforcement. Evaluating requests against the User's configured policies and allowing, blocking, or escalating them.Authorized Representatives initiating requests; persons whose data is referenced in requests. Request content and metadata (representative ID, timestamp, request type); policy decision outcome and rationale.
    5. Audit logging and call analytics. Recording AI-agent interactions, requests, approvals, and policy decisions for traceability and accountability, and recording tool calls for usage analytics and troubleshooting.Authorized Representatives; AI agents (where linked to a natural person); third parties whose data is referenced in logged events. Actor identifier, timestamp, action performed, IP, device/session ID, request/response references.

    Full tool call payloads. In addition to the audit trail above, the Platform stores a record of each tool call that includes the arguments sent to, and the response returned by, the Controller's connected application or API, alongside the acting user's identifier and email address, the source IP address and the user agent. Textual content is stored in full and unredacted: the redaction and truncation described in Clause 3 apply to the audit trail and not to this record. Two qualifications apply. Non-textual blocks in a response — images, audio, PDFs and other binary content — are replaced by a short descriptor before this record is written, so binary payloads themselves are not retained here. And the response of a management tool that releases a credential is replaced by a redaction marker, so released secret values are not retained here either. Because the content of these payloads is determined entirely by what the Controller's agents request from the Controller's own systems, this is the category most likely to contain special category data within the meaning of Art. 9 GDPR, and the Controller should take it into account in the assessment required by Clause 7.1. Retention: see Annex B.
    6. Human-in-the-loop approval workflows. Routing requests to designated Authorized Representatives for review and approval or rejection.Authorized Representatives acting as approvers; data subjects referenced in the request being approved. Identification data; approval decision; rationale; timestamp.
    7. Centralized skill management and distribution. Managing, versioning, and distributing skills used by AI agents through the Platform.Authorized Representatives configuring or using skills; data subjects whose data is processed when a skill is executed. Skill configurations (where they include Personal Data); usage logs; identification data of the configuring/using Representative.
    8. Account and access management. Creating, configuring, modifying, and deactivating User Accounts and Service Accounts; authenticating Authorized Representatives; managing roles and permissions.Authorized Representatives. Name, email, function/role, account status, role/permission attributes.
    9. Usage monitoring, metering, and capacity management. Measuring Accounts and Requests consumed; detecting overruns; monitoring fair-use thresholds and abusive use; conducting independent audits of Platform usage.Authorized Representatives; Service Account principals. Account identifier; counters and usage statistics linked to identifiers; timestamps.
    10. Service-level monitoring (Uptime / Downtime). Measuring availability of the Platform; managing planned and unplanned downtime; notifying the User in advance of maintenance.Authorized Representatives (where availability incidents reference user activity). Contact details for notifications; technical event logs.
    11. Technical support, incident management, and troubleshooting. Receiving, triaging, diagnosing, and responding to support requests sent to support@air-lock.ai; investigating and resolving incidents, including by accessing Customer Data where strictly necessary.Authorized Representatives raising tickets; data subjects whose data is involved in the incident. Contact data; ticket content; incident-specific data accessed for diagnosis.
    12. Maintenance, updates, patching, and security. Performing corrective and preventive maintenance; threat detection; backups; encryption; disaster recovery and similar measures necessary for the proper functioning and security of the Platform.All categories of data subjects to the extent affected by the maintenance/security operation. All Customer Data to the extent strictly necessary; security event logs.
    13. Beta services testing. Making beta services available to opted-in Authorized Representatives and evaluating their use solely for testing/evaluation purposes.Authorized Representatives who opt in to beta services. Any Personal Data inserted by the User during beta testing; usage logs of beta features.
    14. Data export, retention, and deletion at end of service. Making Customer Data available for export during the 60-day period following termination, and deleting/returning Customer Data thereafter.All categories of data subjects represented in the Customer Data still hosted at termination. All Customer Data still hosted at termination.
    15. Sub-processor management. Engaging and managing sub-processors (hosting, infrastructure, analytics, billing providers).All categories of data subjects whose data is transmitted to sub-processors. All Customer Data transmitted, strictly limited to what is necessary for the relevant sub-processing activity.
    16. International transfers (where applicable). Transferring Personal Data to third countries outside the EEA where required for service delivery, subject to Chapter V GDPR safeguards (Standard Contractual Clauses and supplementary measures such as pseudonymization or encryption).All categories of data subjects whose data is transferred. All Personal Data transferred.
    17. Cooperation with the User's GDPR obligations. Assisting the User with data subject rights requests, personal data breach notifications, DPIAs and prior consultations, audits, and demonstration of compliance under Art. 28(3)(e)-(h) GDPR.Data subjects exercising rights or affected by an incident; the User's compliance personnel. Data necessary to identify and locate the data subject's records and to give effect to their rights or to investigate the incident.
    18. Defence of legal claims and audit cooperation. Strictly limited processing where necessary to defend the Company against claims arising from the User's use of the Platform, or to perform contractual audits of Subscription Fee compliance.Persons referenced in the dispute or audit. Data strictly relevant to the claim or audit.

    Annex B. Retention periods

    The following periods apply to Personal Data processed under this DPA. For the log categories, the periods below are reconciled against the Company's internal Logging Policy as described in Clause 6.1; where the two differ, this Annex governs.

    CategoryRetention
    Customer Data held in the Platform (accounts, configuration, credentials, skills, and other data the Controller maintains)For the term of the Agreement, plus the 60-day post-termination export window under Clause 6.2. Credentials are deleted when the Controller deletes the connection.
    Audit trail — operational copy (Annex A, entry 5)90 days, then deleted automatically.
    Audit trail — tamper-resistant archiveAt least 1 year, held under a write-once retention lock applied when each object is written, so that it survives deletion of the operational copy. No automatic expiry runs once the lock ends; archived records are deleted on the Controller's written request from that point. See the stated exception and its two qualifications in Clause 6.2.
    Full tool call payloads (Annex A, entry 5 — complete arguments and responses)No automatic expiry currently applies to this record. It is retained until the Customer Data is deleted or returned under Clause 6.2. The Processor states this rather than implying a shorter period, intends to bound this retention, and will amend this Annex when it does.
    Approval requests and their outcomes (Annex A, entry 6)90 days from creation, then deleted automatically. Where an approved result is too large to store inline, the overflow copy is held in separate object storage and expires 100 days after it is written. Because a request is approved some time after it is created, that copy can outlive the 90-day period of the request it belongs to; the Processor states the two periods separately rather than implying a single one.
    Control-plane and credential-access records (AWS CloudTrail)365 days.
    Infrastructure and application operational logs (short-lived diagnostics; corroborating rather than authoritative)30 days in production, and shorter in non-production environments.
    Product analytics and backend error telemetry (PostHog, Clause 4.2)30 days from the event being recorded. Signing out stops further events being associated with that person; it does not delete events already recorded, and the identifiers listed in Clause 4.2 remain on those historical events until the 30 days expire.
    Data retained under a legal obligation (billing records, compliance records)For the period required by the applicable law, notwithstanding Clause 6.2, as provided in that Clause.

    Contact

    For questions about this DPA or to request a signed copy, contact privacy@air-lock.ai.

    airlock

    Put people on AI and agents to work. Fast and worry free.

    Newsletter

    Product

    • Overview
    • Pricing
    • Integrations
    • Compare

    Resources

    • Documentation
    • Blog
    • FAQ
    • AI Policy generator
    • AI adoption starter kit

    Company

    • Team
    • Contact
    • LinkedIn

    Legal

    • Terms
    • Privacy
    • DPA
    Secured with AikidoSecured with AikidoBacked byStart it @KBC

    EU-hosted · © 2026 Airlock BV