Data Processing Agreement
Version: 2026-11-03
Last Updated: November 3, 2026
This Data Processing Agreement, including its Schedule and Annexes (the "DPA"), forms part of the agreement between AUGLAB LLC, a Florida limited liability company ("augLab"), and the customer that agreed to it ("Customer") for the augLab Service. That agreement is either the Master Subscription and License Agreement and its Order Forms, or, for self-serve plans, the online Terms of Service (in either case, the "Agreement").
How this DPA takes effect.
- Accepted automatically. This DPA is incorporated into the Terms of Service and into every Master Subscription and License Agreement and Order Form. Customer accepts this DPA by accepting any of them, or by using the Service. No separate signature is needed. It applies to all Customer Personal Data that augLab processes, whatever Customer's plan.
- Signed copies. On request to contact@auglab.ai, augLab will provide a countersigned copy for Customer's records. A countersigned copy does not change the terms unless both Parties sign a written amendment.
- Health Data. Schedule 1 (Health Data Schedule) applies automatically to every Customer that submits Health Data to the Service without an executed BAA covering it. That Customer makes the No-PHI commitment and the certification in Section S2 by accepting this DPA, and makes them again each time it submits Health Data.
- PHI. A Customer that is a HIPAA covered entity or business associate must execute augLab's BAA before submitting PHI. This DPA and Schedule 1 do not authorize the submission of PHI.
- Published version. The current version of this DPA is published at auglab.ai/dpa. Updates are governed by Section 12.4.
1. Definitions
Capitalized terms not defined here have the meanings given in the Agreement. The following terms apply whether the Agreement is the Terms of Service or a Master Subscription and License Agreement:
"Agent" means an AI agent, team, workflow, embed, avatar, or other automation that Customer configures in the Service.
"AI Output" means content that a model or Agent generates through the Service for Customer.
"BAA" means a business associate agreement executed by both Parties.
"Customer Content" means data, files, prompts, instructions, knowledge sources, and other content that Customer, its Users, or its End Users submit to the Service, together with AI Output.
"Customer Credentials" means API keys, OAuth tokens, or other credentials for an account that Customer (not augLab) holds with a third-party service.
"Customer-Enabled Services" means third-party services that Customer chooses to connect to or use through the Service. They include model providers reached with Customer Credentials, tools and integrations, webhooks, and MCP servers.
"End User" means a person, other than a User, who interacts with an Agent that Customer deploys.
"HIPAA Mode" means the platform configuration augLab enables for an organization covered by a BAA.
"PHI" means protected health information as defined in 45 C.F.R. § 160.103.
"Platform Credentials" means credentials for accounts that augLab holds with a model provider or other service. This includes those accounts when augLab configures them for Customer's organization. Customer's plan does not change who holds the account.
"User" means a person whom Customer authorizes to use the Service under its account.
"Controller," "Processor," "Data Subject," "Personal Data Breach," "Processing," and "Supervisory Authority" have the meanings given in the GDPR. The equivalent terms in other Data Protection Laws ("business," "service provider," "contractor," "consumer," "controller," "processor," "regulated entity") are read in their place where those laws apply.
"Customer Personal Data" means personal data, personal information, or Health Data contained in Customer Content that augLab processes on Customer's behalf in providing the Service.
"Data Protection Laws" means all laws on privacy, data protection, and data security that apply to the processing of Customer Personal Data under the Agreement. As applicable, they include: (a) the EU General Data Protection Regulation 2016/679 ("GDPR"); (b) the GDPR as incorporated into UK law ("UK GDPR") and the UK Data Protection Act 2018; (c) the Swiss Federal Act on Data Protection ("FADP"); (d) the California Consumer Privacy Act as amended by the California Privacy Rights Act, and its regulations ("CCPA"); (e) the comprehensive consumer privacy laws of other U.S. states (for example Colorado, Connecticut, Delaware, Indiana, Iowa, Kentucky, Maryland, Minnesota, Montana, Nebraska, New Hampshire, New Jersey, Oregon, Rhode Island, Tennessee, Texas, Utah, and Virginia) ("U.S. State Privacy Laws"); (f) the Health Data Laws defined in Schedule 1; and (g) state data breach and data security laws, including Fla. Stat. § 501.171.
"HIPAA" means the Health Insurance Portability and Accountability Act of 1996, the HITECH Act, and their implementing regulations at 45 C.F.R. Parts 160 and 164.
"Restricted Transfer" means a transfer of Customer Personal Data subject to the GDPR, UK GDPR, or FADP to a country that the relevant authority has not found to provide adequate protection.
"Security Incident" means a breach of security leading to the accidental or unlawful destruction, loss, alteration, or unauthorized disclosure of, or access to, Customer Personal Data while it is processed by augLab or its Subprocessors. Unsuccessful attempts and activities that do not compromise the security of Customer Personal Data are not Security Incidents. Examples include pings, port scans, blocked log-in attempts, and denial-of-service attacks that do not result in access to data.
"Standard Contractual Clauses" or "SCCs" means the clauses annexed to European Commission Implementing Decision (EU) 2021/914.
"Subprocessor" means a third party that augLab engages to process Customer Personal Data on Customer's behalf. Customer-Enabled Services are not Subprocessors (see Section 6.5).
2. Roles and Scope
2.1 Roles. For Customer Personal Data, Customer is the Controller (or "business" or "regulated entity") and augLab is a Processor (or "service provider," "contractor," or "processor"). If Customer is itself a Processor acting for a third-party Controller, augLab is Customer's sub-processor. Customer is responsible for obtaining that Controller's authorizations and for relaying its instructions.
2.2 augLab as Controller. augLab is an independent Controller of account, billing, and support data about Customer's Users and of Usage Data, as described in augLab's Privacy Policy. This DPA does not apply to that data.
2.3 Details of Processing. Annex I describes the subject matter, duration, nature and purpose of the processing, the types of Customer Personal Data, and the categories of Data Subjects.
2.4 HIPAA. This DPA is not a business associate agreement. Where Customer Personal Data is PHI, augLab processes it only under an executed BAA, and the BAA prevails over this DPA for that PHI. Where Customer Personal Data is Health Data that is not PHI, Schedule 1 applies if elected.
3. Customer Obligations
3.1 Customer will comply with Data Protection Laws in its use of the Service and in the instructions it gives augLab.
3.2 Customer is responsible for the lawfulness of the Customer Personal Data it provides. This includes having a lawful basis (and, for special category data, a condition under GDPR Article 9), providing required privacy notices, and obtaining required consents and authorizations, including from End Users of its Agents.
3.3 Customer decides which models, model providers, tools, integrations, and knowledge sources its Agents use. Customer is responsible for those choices and for the onward transfers they cause, including transfers to providers outside its jurisdiction.
3.4 Customer will not submit Restricted Data except as permitted in the Agreement.
4. augLab Obligations
4.1 Instructions. augLab will process Customer Personal Data only on Customer's documented instructions, including with regard to Restricted Transfers, unless required to do otherwise by law. If the law requires otherwise, augLab will inform Customer before processing, unless the law prohibits it. The Agreement, this DPA, Customer's configuration of the Service, and its Users' use of the Service are Customer's complete instructions. Additional instructions require written agreement. augLab will promptly inform Customer if, in its opinion, an instruction infringes Data Protection Laws. augLab may then suspend the affected processing until Customer withdraws or confirms the instruction.
4.2 Confidentiality. augLab will ensure that personnel authorized to process Customer Personal Data are bound by written confidentiality obligations and receive appropriate data protection training.
4.3 Security. augLab will implement and maintain the technical and organizational measures in Annex II. augLab may update those measures, but it will not materially decrease the overall protection of Customer Personal Data.
4.4 No Training; No Secondary Use. augLab will not use Customer Personal Data to train or improve any AI or machine learning model, and will not use it for advertising, profiling, or any purpose other than providing the Service under the Agreement.
4.5 Assistance. Taking into account the nature of the processing and the information available to it, augLab will provide reasonable assistance to Customer with data protection impact assessments, prior consultations with Supervisory Authorities, and Customer's security obligations under Data Protection Laws. augLab may charge reasonable fees for assistance that goes beyond the features and documentation of the Service.
5. Data Subject Requests
5.1 The Service lets Customer access, correct, export, and delete Customer Personal Data. Customer will use those features to respond to Data Subject requests where it can.
5.2 If augLab receives a request from a Data Subject about Customer Personal Data, augLab will direct the requester to Customer and will not respond itself except to confirm the redirection, unless law requires a response. augLab will notify Customer of the request without undue delay, unless the law prohibits it.
5.3 If Customer cannot respond to a request using the Service, augLab will provide reasonable assistance on Customer's written request.
6. Subprocessors
6.1 Authorization. Customer gives general authorization for augLab to engage Subprocessors. The Subprocessors in Annex III are authorized as of the date of this DPA.
6.2 Requirements. augLab will (a) impose data protection obligations on each Subprocessor by written contract that are no less protective than this DPA, to the extent they apply to the Subprocessor's services, and (b) remain responsible to Customer for each Subprocessor's performance of those obligations.
6.3 Changes. augLab will notify Customer at least thirty (30) days before a new Subprocessor begins processing Customer Personal Data. Notice is given by email to Customer's account administrators or to an address Customer registers for Subprocessor notices. Where an urgent replacement is needed for security or continuity, augLab will give notice as soon as practicable.
6.4 Objection. Customer may object to a new Subprocessor on reasonable data protection grounds by written notice within fourteen (14) days after augLab's notice. The Parties will discuss the objection in good faith. If it is not resolved within thirty (30) days, Customer may, as its sole remedy, terminate the part of the Service that cannot be provided without that Subprocessor and receive a refund of prepaid fees for the remainder of the term for that part.
6.5 Customer-Enabled Services. When Customer configures the Service to send Customer Personal Data to a Customer-Enabled Service, Customer directs that transfer. The recipient processes the data under Customer's own agreement with it, not as augLab's Subprocessor. This includes model providers reached with Customer Credentials, and tools and integrations such as email, messaging, calendar, file storage, CRM, web search, webhooks, and MCP servers. augLab's obligations under this DPA end when the data leaves the Service for that recipient.
6.6 Model Providers Using Platform Credentials. Model providers that augLab reaches with Platform Credentials are Subprocessors. They process Customer Personal Data to generate responses. Under their terms they may keep request data for a limited period to monitor for abuse, unless a zero-data-retention or similar arrangement applies. Annex III states augLab's arrangement with each provider. Organizations with HIPAA Mode or Health Data Safeguards enabled can send content only to the providers permitted for that organization.
7. Security Incidents
7.1 Notice. augLab will notify Customer of a Security Incident without undue delay, and in any event within seventy-two (72) hours after augLab confirms it. Notice goes to Customer's designated security contact (or, if none, its account administrators).
7.2 Content. To the extent known, the notice will describe the nature of the incident; the categories and approximate number of Data Subjects and records concerned; the likely consequences; the measures taken or proposed to address it; and a contact point. augLab will supplement the notice as information becomes available.
7.3 Cooperation. augLab will take reasonable steps to contain, investigate, and mitigate the Security Incident. It will reasonably cooperate with Customer in meeting Customer's notification obligations to Supervisory Authorities, regulators, and individuals. Customer is responsible for those notifications unless the law requires augLab to make them directly. augLab will not notify Customer's Data Subjects or regulators about a Security Incident affecting Customer Personal Data without Customer's consent, except where the law requires it.
7.4 No Admission. augLab's notice of, or response to, a Security Incident is not an acknowledgment of fault or liability.
8. Audits
8.1 Documentation. On written request, no more than once in any twelve (12) month period, augLab will provide information reasonably necessary to demonstrate compliance with this DPA. This includes its security policies, a summary of its most recent risk assessment, its responses to a reasonable industry-standard security questionnaire, and any third-party assurance reports or certifications it then holds. All of it is augLab's Confidential Information.
8.2 Audits. If the information in Section 8.1 is not enough to demonstrate compliance with this DPA or Data Protection Laws, or if a Supervisory Authority or regulator requires it, Customer may conduct an audit, or have one conducted by an independent auditor bound by confidentiality who is not a competitor of augLab. Customer must give at least thirty (30) days' notice. The audit is limited to once in any twelve (12) month period, except after a Security Incident affecting Customer or at a regulator's request. It must be conducted during business hours and must not unreasonably interfere with augLab's operations or compromise the data of other customers. Customer bears its own audit costs. If an audit requires more than two (2) days of augLab personnel time, augLab may charge reasonable fees for that time.
8.3 SCC Audits. Audits under the SCCs are carried out under this Section 8.
9. Return and Deletion
9.1 During the Term. Customer may delete Customer Personal Data at any time using the Service. Customer may also set retention periods for its organization. augLab deletes data from live systems according to those settings.
9.2 After Termination. For thirty (30) days after the Agreement ends, augLab will, on request, make Customer Personal Data available for export. augLab will then delete Customer Personal Data from its live systems within thirty (30) days. Copies in backups are not restored except for disaster recovery. They remain protected by this DPA and are overwritten as backups expire on augLab's regular backup rotation schedule. On request, augLab will confirm deletion in writing.
9.3 Exceptions. augLab may retain Customer Personal Data where the law requires it. It may also retain audit logs as a BAA or Annex II requires. Retained data remains subject to this DPA and is used only for the purpose that requires its retention.
10. International Transfers
10.1 Location. augLab hosts Customer Content in the United States. Model providers and other Subprocessors process data in the locations listed in Annex III.
10.2 EEA Transfers. For Restricted Transfers from the EEA, the SCCs are incorporated into this DPA. Module Two (controller to processor) applies where Customer is a Controller, and Module Three (processor to processor) applies where Customer is a Processor. For both: (a) Clause 7 (docking clause) applies; (b) under Clause 9(a), Option 2 (general written authorization) applies, with the notice period in Section 6.3; (c) the optional language in Clause 11(a) does not apply; (d) under Clause 13, the competent Supervisory Authority is that of Customer's EU representative or establishment, as Annex I indicates; (e) under Clauses 17 and 18, the governing law and forum are those of Ireland; and (f) Annexes I, II, and III of the SCCs are completed by Annexes I, II, and III of this DPA.
10.3 UK Transfers. For Restricted Transfers subject to the UK GDPR, the SCCs apply as amended by the International Data Transfer Addendum issued by the UK Information Commissioner (version B1.0 or its successor) (the "UK Addendum"). Table 1 of the UK Addendum is completed with the Parties' details in Annex I. Tables 2 and 3 are completed by Section 10.2 and Annexes I–III. In Table 4, either Party may end the UK Addendum as allowed by Section 19 of the UK Addendum.
10.4 Swiss Transfers. For Restricted Transfers subject to the FADP, the SCCs apply with these changes: references to the GDPR are read as references to the FADP; the competent authority is the Swiss Federal Data Protection and Information Commissioner; and "Member State" includes Switzerland, so Data Subjects in Switzerland can bring claims there.
10.5 Conflict. If the SCCs conflict with this DPA, the SCCs prevail for the transfers they cover.
10.6 Customer-Selected Providers Outside Adequate Countries. Some model providers that Customer may select process data in countries without an adequacy decision (see Annex III). Before selecting such a provider for EEA, UK, or Swiss personal data, Customer is responsible for completing its own transfer assessment.
11. U.S. State Privacy Law Terms
Where the CCPA or another U.S. State Privacy Law applies to Customer Personal Data:
11.1 Customer discloses Customer Personal Data to augLab only for the limited and specified business purposes in Annex I.
11.2 augLab will not: (a) sell or share Customer Personal Data, as those terms are defined in the CCPA; (b) retain, use, or disclose Customer Personal Data for any purpose, including any commercial purpose, other than the business purposes in Annex I, or outside the direct business relationship between augLab and Customer, except as the CCPA permits; (c) combine Customer Personal Data with personal information that augLab receives from or on behalf of another person or collects from its own interactions with consumers, except as the CCPA permits; or (d) use Customer Personal Data for targeted advertising or cross-context behavioral advertising.
11.3 augLab will comply with the CCPA and other applicable U.S. State Privacy Laws. It will provide the same level of privacy protection those laws require of Customer. It will notify Customer if it determines it can no longer meet its obligations under them.
11.4 Customer may take reasonable and appropriate steps to ensure that augLab uses Customer Personal Data in a manner consistent with Customer's obligations, and, on notice, to stop and remediate unauthorized use. These steps include the steps in Section 8.
11.5 If augLab receives de-identified data from Customer, augLab will not attempt to re-identify it. It will maintain the measures required by the CCPA for de-identified information.
11.6 augLab will impose these obligations on Subprocessors by contract, and it will notify Customer of new Subprocessors under Section 6.3.
11.7 augLab certifies that it understands and will comply with the restrictions in this Section 11.
12. Liability and General Terms
12.1 Liability. Each Party's liability arising out of or relating to this DPA, including the SCCs to the extent permitted by them, is subject to the exclusions and limitations of liability in the Agreement. This DPA does not create a separate or additional liability cap.
12.2 Order of Precedence. If documents conflict, this order applies: (a) a BAA, as to PHI; (b) the SCCs, as to Restricted Transfers; (c) Schedule 1, as to Health Data; (d) the rest of this DPA; and (e) the Agreement.
12.3 Term. This DPA remains in effect for as long as augLab processes Customer Personal Data under the Agreement.
12.4 Updates. augLab may update this DPA by publishing a new version at auglab.ai/dpa. Updates that are required by changes in Data Protection Laws, or that do not materially reduce the protection given to Customer Personal Data, take effect on publication. augLab will give at least thirty (30) days' notice of any other material update. For a Customer with a signed Master Subscription and License Agreement, an update that materially reduces that protection does not apply until its next renewal term, unless Customer agrees to it in writing.
Schedule 1: Health Data Schedule and Non-Covered Entity Certification
This Schedule applies to every customer that submits health information to the Service without an executed BAA. Such a customer is relying on its own determination that it is not a HIPAA covered entity or business associate for that information. Examples include cash-pay or membership practices, wellness and coaching businesses, digital health companies, employers, researchers, and any other organization that handles health information but does not conduct HIPAA standard transactions. This Schedule does not replace a BAA. A customer that is a covered entity or business associate must sign the BAA instead.
Customer alone determines its HIPAA status. augLab does not advise on, verify, or assume responsibility for that determination. Customer should consult its own counsel.
S1. Definitions
"Health Data" means information in Customer Content that identifies, or is reasonably linkable to, an individual and that relates to that individual's past, present, or future physical or mental health, health condition, treatment, diagnosis, procedures, medications, biometric or genetic data, or the provision of or payment for health care, whether or not it is PHI. It includes "consumer health data," "medical information," and similar terms under Health Data Laws.
"Health Data Laws" means laws, other than HIPAA, that govern the privacy, security, or breach notification of Health Data, to the extent applicable to the Parties. As applicable, they include: (a) the Washington My Health My Data Act (RCW ch. 19.373); (b) Nevada SB 370 (NRS ch. 603A consumer health data provisions); (c) the consumer health data provisions of the Connecticut Data Privacy Act; (d) the California Confidentiality of Medical Information Act (Cal. Civ. Code § 56 et seq.); (e) the Texas Medical Records Privacy Act (Tex. Health & Safety Code ch. 181); (f) Florida's patient records laws (including Fla. Stat. § 456.057) and Fla. Stat. § 501.171; (g) state genetic privacy laws (including Fla. Stat. § 760.40); (h) the FTC Act and the FTC Health Breach Notification Rule (16 C.F.R. Part 318); and (i) the sensitive-data provisions of U.S. State Privacy Laws.
"Health Data Safeguards" means the controls described in Section S5.
S2. No-PHI Commitment and Non-Covered Entity Certification
S2.0 No PHI. Customer will not upload, submit, collect through an Agent or embed, or otherwise transmit PHI to the Service unless a BAA is in effect and augLab has confirmed in writing that HIPAA Mode is enabled for the receiving organization. augLab does not agree to receive, and does not accept, PHI under this DPA or the Agreement. Any PHI submitted in breach of this Section S2.0 is submitted at Customer's sole risk. augLab has no obligations under HIPAA for it, and Section S2.5 applies.
S2.1 Customer certifies, represents, and warrants that each of the following is true. The certification is made when Customer accepts this DPA, again each time Customer submits Health Data to the Service without an executed BAA, and again when Customer completes Annex A (if augLab requests it). It continues while this Schedule is in effect.
(a) Not a covered entity. Neither Customer nor any health care provider whose patient information Customer submits to the Service (including Customer's owners, affiliated practices, and practitioners) is a "covered entity" under 45 C.F.R. § 160.103. In particular, none of them transmits health information in electronic form in connection with a HIPAA standard transaction, whether directly or through a billing service, clearinghouse, or other agent. HIPAA standard transactions include health care claims or encounter information, eligibility inquiries, claim status inquiries, referral certification and authorization, health care payment and remittance advice, coordination of benefits, and enrollment;
(b) Not a business associate. Customer is not submitting the Health Data as a business associate of a covered entity, and the Health Data was not received from a covered entity under a business associate arrangement;
(c) Not PHI. To Customer's knowledge after reasonable inquiry, the Health Data submitted to the Service is not PHI; and
(d) Accuracy of information. Any information Customer provides to augLab about its HIPAA status, including in Annex A or an Order Form, is complete and accurate.
S2.2 Patient-submitted claims. Giving patients receipts or "superbills" that the patients submit to their own health plans does not, by itself, make Customer a covered entity. If Customer, or anyone acting for Customer, submits a claim or eligibility inquiry electronically, Customer is a covered entity and this Schedule no longer applies.
S2.3 Change in status. Customer will notify augLab in writing at least thirty (30) days before, or if that is not possible, immediately upon, any change that would make the representations in Section S2.1 untrue. Examples of such changes include enrolling with Medicare, Medicaid, or any health plan; electronically submitting claims or eligibility inquiries; engaging a billing service or clearinghouse; affiliating with a covered entity; or receiving data from a covered entity. From the date of the change, Customer will not submit PHI to the Service unless and until (i) the Parties have executed a BAA, (ii) Customer is on a plan that supports HIPAA Mode, and (iii) augLab has confirmed in writing that HIPAA Mode is enabled for Customer's organization.
S2.4 Reliance. augLab relies on Customer's representations in this Section S2 in agreeing to provide the Service without a BAA. augLab is not obligated to investigate them. If augLab reasonably believes the representations are or have become inaccurate, augLab may suspend processing of Health Data, or terminate the affected Order Form, until the Parties resolve the matter, including by executing a BAA.
S2.5 Indemnity. Customer will defend, indemnify, and hold harmless augLab, its Affiliates, and their officers, members, employees, and agents. The indemnity covers all claims, regulatory investigations, penalties, fines, damages, notification and remediation costs, and reasonable attorneys' fees arising from (a) any PHI submitted in breach of Section S2.0, (b) any inaccuracy in the certification in Section S2.1 or in information Customer provides about its status, (c) Customer's failure to give notice under Section S2.3, or (d) Customer's breach of Section S4. This obligation is an Excluded Claim under the Agreement and is not subject to its limitations of liability.
S3. Acknowledgments
S3.1 Not a business associate. Based on Customer's representations, the Parties agree that augLab is not acting as Customer's business associate. They also agree that no BAA exists between them for the Health Data unless they separately sign one. augLab makes no representation that the Service, or Customer's use of it, satisfies HIPAA.
S3.2 HIPAA Mode controls are technical controls. augLab may implement Health Data Safeguards using the same platform controls it uses for HIPAA Mode. Enabling those controls is not an agreement by augLab to act as a business associate, and does not represent that any data is or is not PHI.
S3.3 Allocation of risk. If Customer is, or becomes, a covered entity or business associate for any data submitted to the Service while no BAA is in effect, that is a breach of this Schedule by Customer. Customer is then responsible for any resulting liability, penalties, and remediation costs under Section S2.5. augLab has no liability to Customer for failing to perform obligations under HIPAA that would have applied only if a BAA had been in effect.
S4. Customer Obligations for Health Data
Customer is solely responsible for:
(a) Notices and consents. Giving individuals all notices, and obtaining all consents and authorizations, that Health Data Laws require for Customer to collect Health Data and to have augLab process it. This includes a consumer health data privacy policy and consent for collection and sharing where the Washington My Health My Data Act or similar laws apply.
(b) Medical records laws. Determining whether state medical records and professional confidentiality laws (for example Fla. Stat. § 456.057) require a patient's written authorization before Customer submits patient records to a technology vendor. Customer must obtain that authorization where required.
(c) Patient-facing Agents. For any Agent that communicates with patients or the public, Customer must:
- disclose the use of AI where law requires it (for example Cal. Health & Safety Code § 1339.75);
- make sure the Agent does not hold itself out as a licensed professional;
- make sure the Agent directs individuals to emergency services when appropriate; and
- provide a path to a human.
(d) Clinical decisions. Making sure a qualified, licensed professional reviews AI Output before it is used in any decision about diagnosis, treatment, prescribing, products, supplements, dosing, procedures, or triage. The Service is not a medical device or clinical decision support tool.
(e) Marketing and claims. Making sure health, efficacy, and safety claims in content generated or sent through the Service are truthful, substantiated, and lawful. Applicable rules include the FTC Act, FDA requirements for drugs, biologics, devices, and supplements, and state consumer protection and professional advertising rules. Customer must also obtain consent before using Health Data for marketing.
(f) Messaging and recordings. Complying with the TCPA, CAN-SPAM, and state messaging laws for patient outreach, and with all-party-consent recording laws (including Fla. Stat. § 934.03) for any call, visit, or meeting recording or transcription.
(g) Configuration. Keeping the Health Data Safeguards in place, limiting access to Users who need it, and choosing tools and Customer-Enabled Services that are appropriate for Health Data. This includes model providers whose terms Customer has reviewed, preferring zero-data-retention or no-training arrangements. Customer must not connect Health Data to tools that publish, broadcast, or share it, such as public chat shares, unrestricted webhooks, social media posting, or advertising pixels. Health Data Safeguards are optional. If Customer does not request them, disables them, or uses model providers, tools, or settings they would not permit, Customer does so at its own risk. In that case, Customer agrees that the measures in Annex II are appropriate for its Health Data, and augLab has no liability arising from that choice.
(h) Website tracking. Making sure websites and pages where Customer installs augLab embeds do not send Health Data to advertising or analytics vendors without the consents Health Data Laws require.
(i) Excluded data. Not submitting (i) records subject to 42 C.F.R. Part 2; (ii) genetic test results or genetic data, unless Customer has obtained the consents genetic privacy laws require; or (iii) Health Data of minors, unless Customer has obtained required parental or guardian consent.
(j) Notifications. Determining whether a Security Incident affecting Health Data triggers notification obligations under Health Data Laws, including the FTC Health Breach Notification Rule, and making any required notifications to individuals, regulators, and the media.
S5. augLab Obligations for Health Data
For an organization covered by this Schedule, augLab will:
(a) Restrict processing. Process Health Data only on Customer's documented instructions under Section 4.1 of this DPA and for the business purposes in Annex I. augLab will not collect, use, or disclose Health Data for any other purpose. This Section S5(a) is intended to satisfy the processor contract requirements of the Washington My Health My Data Act and similar Health Data Laws.
(b) No sale, advertising, or training. Not sell Health Data, use it for targeted advertising or profiling, or use it to train or improve AI models.
(c) Enable Health Data Safeguards. On Customer's written request, enable the following platform controls for Customer's organization. They are available on plans that support them (currently Enterprise). augLab may require Customer to complete Annex A first.
- mandatory multi-factor authentication for all members (including SSO users);
- automatic logoff after fifteen (15) minutes of inactivity;
- application-level AES-256-GCM encryption of run content, chat, uploads, memories, and evaluation data;
- audit logging of access to content routes;
- PHI-safe error handling that keeps content out of logs and error tracking;
- disabling public chat sharing; and
- restricting model providers to those approved for the organization.
augLab may change how these controls are implemented, provided it does not materially reduce the protection they provide.
(d) Data location. Store Health Data at rest only in the United States. Data that Customer sends to Customer-Enabled Services is stored where those services store it.
(e) Assistance. Provide reasonable assistance with individuals' requests to access, correct, or delete Health Data, and with Customer's compliance obligations under Health Data Laws, under Section 5 of this DPA.
(f) Incident notice. Notify Customer of a Security Incident involving Health Data under Section 7 of this DPA, within seventy-two (72) hours after augLab confirms it. augLab will provide the information Customer reasonably needs to meet its own notification obligations, including the third-party agent notice under Fla. Stat. § 501.171(6).
(g) Personnel. Limit access to Health Data to augLab personnel who need it to provide the Service and who have completed augLab's privacy and security training.
(h) Deletion. Delete Health Data under Section 9 of this DPA.
S6. Provider Restrictions
S6.1 Platform Credentials. Where Customer's Agents use models through Platform Credentials, the model provider is augLab's Subprocessor (Section 6.6 and Annex III). Knowledge-base embeddings and search, and optional moderation, use Platform Credentials even when Customer's Agents use Customer Credentials. augLab's agreement with that provider governs its processing. augLab will not permit the provider to use Customer Content to train models.
S6.2 Customer Credentials. Where Customer uses Customer Credentials, the provider is a Customer-Enabled Service. Customer is responsible for its agreement with that provider, including data retention and use terms. If Customer uses a routing service, such as OpenRouter, Customer is also responsible for the downstream providers it routes to. That includes the routing service's privacy settings, for example excluding providers that may train on or retain prompts.
S6.3 Approved providers. Once Health Data Safeguards are enabled, the platform enforces the organization's approved provider list. augLab will not route Health Data through platform decision features, AI-assisted creation features, or other platform features whose provider is not on that list.
S7. Termination of Schedule
This Schedule ends when the Agreement ends, or earlier by mutual written agreement, or when a BAA replaces it. If Customer notifies augLab of a change in status under Section S2.3, the Parties will work in good faith to execute a BAA. If no BAA is executed within thirty (30) days, either Party may terminate the affected Order Form, and Customer must stop submitting PHI immediately.
Annex A to Schedule 1: Health Data Profile
The certification in Section S2 binds Customer on acceptance of this DPA, whether or not Customer completes this Annex. augLab may ask a Customer that handles Health Data to complete this Annex before enabling Health Data Safeguards. Each response is a representation and warranty under Section S2, and Section S2.5 applies to any inaccuracy.
| Item | Customer response |
|---|---|
| Customer legal name and state(s) of operation | |
| Nature of Customer's business and the health-related services it provides | |
| States where patients reside (affects which Health Data Laws apply) | |
| Does Customer, or anyone acting for it, submit claims, eligibility checks, or other transactions to any health plan, Medicare, or Medicaid electronically? | ☐ No ☐ Yes (stop: BAA required) |
| Has Customer or any practitioner opted out of Medicare, or does any practitioner bill Medicare or other plans for services delivered at Customer? Describe. | |
| Does Customer use a billing service, clearinghouse, or practice management system that submits transactions to health plans? | ☐ No ☐ Yes (describe) |
| Does Customer give patients superbills to submit themselves? | ☐ No ☐ Yes |
| Does Customer receive patient data from hospitals, physicians, labs, or other covered entities under a BAA? | ☐ No ☐ Yes (describe) |
| Intended uses of the Service (e.g., intake, scheduling, follow-up messaging, marketing content, internal knowledge base, visit notes) | |
| Will Agents communicate directly with patients or prospective patients? | ☐ No ☐ Yes (Section S4(c) applies) |
| Will the Service record or transcribe patient conversations? | ☐ No ☐ Yes (Section S4(f) applies) |
| Genetic data permitted? | ☐ No ☐ Yes (consents required) |
| Data of minors permitted? | ☐ No ☐ Yes (parental consent required) |
| Approved model providers for this organization (for example OpenAI, Anthropic) | |
| Model credentials | ☐ Platform Credentials (augLab's provider accounts) ☐ Customer Credentials (Customer's own provider agreements) |
| Customer privacy/security contact for incident notices |
Customer certification. On behalf of Customer, I certify that:
- Customer is not a HIPAA covered entity.
- Customer is not submitting Health Data as a business associate of a covered entity.
- Customer has made this determination on its own, with advice of its own counsel as it considers appropriate, and not in reliance on augLab.
- The responses above are accurate and complete.
- Customer will notify augLab under Section S2.3 before its status changes.
I am authorized to make this certification on Customer's behalf.
| Name | Title | Signature | Date |
|---|---|---|---|
Annex I: Details of Processing
A. List of Parties
| Data exporter | Data importer | |
|---|---|---|
| Name | Customer, as identified in the Agreement | AUGLAB LLC |
| Address | As stated in the Agreement or Customer's account | Florida, United States (contact@auglab.ai) |
| Contact | Customer's account administrator or designated privacy contact | Privacy Officer, tim@auglab.ai |
| Role | Controller (or Processor acting for a Controller) | Processor (or sub-processor) |
| Activities | Use of the Service | Provision of the Service |
| Signature and date | Deemed signed on acceptance of the Agreement | Deemed signed on acceptance of the Agreement |
B. Description of Processing
| Item | Description |
|---|---|
| Categories of Data Subjects | Customer's Users; End Users who interact with Customer's Agents and embeds; individuals whose data Customer includes in Customer Content (for example Customer's customers, patients, prospects, and personnel) |
| Categories of personal data | Identifiers and contact details; content of prompts, files, chats, form submissions, knowledge sources, memories, and AI Output; metadata about runs and messages; any other data Customer chooses to submit |
| Sensitive / special category data | Only if Customer submits it. This may include health data, subject to the BAA (for PHI) or Schedule 1 (for Health Data). Applied safeguards: the measures in Annex II and, where elected, HIPAA Mode or Health Data Safeguards |
| Frequency of transfer | Continuous, for as long as Customer uses the Service |
| Nature of processing | Hosting, storage, retrieval, embedding and indexing, transmission to model providers and tools that Customer selects, generation of AI Output, display, export, deletion, backup, security monitoring, and support |
| Business purposes | Providing, maintaining, securing, and supporting the Service under the Agreement; preventing fraud and abuse; complying with law |
| Retention | During the Agreement, subject to Customer's retention settings, and afterward per Section 9 |
| Subprocessor transfers | As described in Annex III, for the purposes stated there |
| Competent Supervisory Authority | That of Customer's establishment or EU representative, or, if none, the Irish Data Protection Commission |
Annex II: Technical and Organizational Measures
| Area | Measures |
|---|---|
| Governance | Designated Privacy Officer and Security Officer; written security policy; annual risk assessment; vendor and subprocessor register reviewed quarterly |
| Personnel | Confidentiality obligations; security and privacy training at onboarding and annually; HIPAA workforce training for personnel with access to production; sanctions policy; access removed on departure |
| Access control | Unique user accounts; role-based access with organization-scoped tenant isolation; multi-factor authentication (TOTP), mandatory for privileged accounts and for HIPAA Mode and Health Data Safeguards organizations; SSO (SAML 2.0 and OpenID Connect); account lockout after repeated failed log-ins; password complexity rules; idle session timeout; time-limited, reason-logged emergency access for augLab administrators to protected organizations; periodic access reviews |
| Encryption | TLS for data in transit, with HSTS; application-level AES-256-GCM encryption of run inputs and outputs, chat messages, uploads, memories, evaluation data, job payloads, and live run streams, with keys derived using HKDF-SHA256; encrypted storage of stored third-party credentials; hosting-provider encryption for other data at rest and backups |
| Logging and monitoring | Tamper-evident, hash-chained audit logs of security-relevant and content-access events; daily integrity verification of audit chains; content redaction in application logs and error tracking; optional forwarding of audit events to Customer's SIEM |
| Application security | Code review and automated tests before release; dependency vulnerability scanning in CI; rate limiting; signed webhooks; security headers and content security policy; restricted model and tool policies set by organization admins |
| Availability and resilience | Managed database with automated backups and point-in-time recovery; documented disaster recovery plan with recovery time and recovery point objectives; restore testing |
| Incident response | Documented incident response plan; breach notification procedures; post-incident review |
| Data minimization and deletion | Configurable retention per organization; self-service export and deletion; deletion after termination per Section 9 |
| Subprocessor management | Security review before engagement; written data protection terms; BAAs before any PHI flows to a subprocessor |
| Customer controls | Organization roles, guardrails, approval gates, model and tool allowlists, budget limits, retention settings, and audit log access |
Annex III: Subprocessors
Infrastructure and operations (always or commonly used)
| Subprocessor | Purpose | Data | Location |
|---|---|---|---|
| Render | Application hosting, PostgreSQL, Redis, backups | All Customer Content | United States |
| Sentry | Error tracking | Redacted error events and request metadata; no request bodies | United States |
| Email delivery provider | Transactional email (invitations, password resets, notifications) | Name, email address, message metadata | United States |
| Stripe | Billing for self-serve plans | Billing contact, organization name; payment details held by Stripe | United States |
Model providers (used when Customer selects their models, or for platform features, with Platform Credentials)
| Subprocessor | Purpose | Location | Platform features |
|---|---|---|---|
| OpenAI | Model inference, embeddings, moderation | United States | Default knowledge embeddings; optional moderation and classifier guardrails |
| Anthropic | Model inference | United States | — |
| OpenRouter | Model routing to the underlying model provider | United States, then the underlying provider's location | Decision features and AI-assisted creation |
| Google (Gemini API) | Model inference, embeddings | United States | — |
| Mistral | Model inference, embeddings | European Union | — |
| Cohere | Model inference, embeddings | United States / Canada | — |
| Groq | Model inference | United States | — |
| xAI | Model inference | United States | — |
| Perplexity | Model inference and search | United States | — |
| DeepSeek | Model inference | People's Republic of China | — |
Model providers receive content only when an Agent, knowledge source, or platform feature uses them. When Customer uses Customer Credentials for a provider, that provider is a Customer-Enabled Service, not a Subprocessor (Section 6.5).
HIPAA Mode and Health Data Safeguards organizations. Content from these organizations goes only to the providers permitted for the organization. HIPAA Mode organizations use their own provider credentials under their own business associate agreements with those providers. Platform features that would send their content over augLab's credentials are disabled for them.