KaizenProof

Data processing agreement

Last updated: 9 October 2026 · Version 1.1

This Data Processing Agreement ("DPA") is between the Customer that accepts the KaizenProof Terms of Service (the "Customer", controller) and Capital AI Srl, P.IVA 13856590966 ("Capital AI", processor; contact vincent@capital-ai.eu). It is accepted together with the Terms, in the same way, and forms part of them. It is meant to meet Article 28(3) of Regulation (EU) 2016/679 ("GDPR").

1. Subject matter and duration

1.1 Capital AI processes personal data contained in Customer Content (as defined in the Terms) to provide KaizenProof to the Customer.

1.2 This DPA lasts as long as Capital AI holds Customer personal data under the Terms, and ends when that data has been deleted under section 12.

2. Nature and purpose

Capital AI stores, displays, analyses and transmits Customer personal data to:

  • store the Customer's workspace and show it to the Customer's members;
  • send friction text and related content to the model provider for classification, the why questions, countermeasure generation and duplicate suggestions, and store the result;
  • send check-in emails to the member who owns a countermeasure, and invitation emails to addresses chosen by a workspace owner;
  • compute the workspace totals (hours identified and confirmed), the dashboard and the weekly summary;
  • store the workspace's brand on templates (a name, two colours and a logo) and place it on the template files generated, on request, for the workspace's members; those files are not stored;
  • enforce the service's limits and keep it secure;
  • give workspace owners a download of all workspace data;
  • delete data when the Customer or its members delete it.

Annex 1 gives the details.

3. The Customer's instructions and responsibilities

3.1 The Terms, this DPA and the Customer's use of the product's functions (what members type, whom owners invite or remove, what they delete) are the Customer's complete documented instructions. Capital AI will tell the Customer if it believes an instruction breaks the GDPR or other EU or member state data protection law.

3.2 The Customer is responsible for: having a legal basis for the processing; informing its members and anyone named in workspace content; meeting any obligations under employment law, including on tools that could be used to monitor workers and on consulting employee representatives; and making sure members do not enter data that section 8 of the Terms forbids, including special categories of data.

3.3 Friction text can contain information about colleagues. Members describe work problems in their own words, and the product does not check or filter what they type. A friction, an answer or a rejection reason can name or describe colleagues, managers, customers or suppliers who have no account. The Customer is the controller of that information.

4. Capital AI's obligations

Capital AI will:

(a) process Customer personal data only on the Customer's documented instructions, including for transfers outside the EEA (section 8), unless EU or member state law requires otherwise, in which case it will tell the Customer first unless that law forbids it;

(b) ensure that people authorised to process the data are bound by confidentiality (section 5);

(c) take the security measures in Annex 2 (Art. 32);

(d) use sub-processors only as in section 7;

(e) assist the Customer with data-subject requests (section 9);

(f) assist the Customer with security, breach notification, impact assessments and prior consultation (Arts. 32 to 36), taking into account the nature of the processing and the information available to Capital AI (sections 10 and 11);

(g) delete Customer personal data at the end of the service (section 12);

(h) make available the information needed to demonstrate compliance with Article 28, and allow for audits (section 13).

5. People

Access to production data at Capital AI is limited to the people Capital AI authorises for that purpose, who are bound by confidentiality. They access Customer Content only to provide or secure the service, to investigate a problem the Customer reports, or as the law requires. There is no technical access log of such access today (Annex 2).

6. Security

Capital AI takes the measures in Annex 2. They may change over time but will not fall below the level described there.

7. Sub-processors

7.1 The Customer gives general authorisation for Capital AI to use the sub-processors listed on the sub-processors page at the date of acceptance.

7.2 Capital AI uses each sub-processor under that provider's data processing terms, which impose data protection obligations on it, and remains responsible to the Customer for them.

7.3 Changes. Capital AI will add a new sub-processor to the sub-processors page, with an entry in its change log, at least 30 days before it processes Customer personal data. The Customer may object on reasonable data protection grounds within that period by writing to vincent@capital-ai.eu. If the parties cannot resolve the objection, the Customer may end the Terms and delete its workspace.

7.4 In an emergency (a provider failing, or a security need), Capital AI may replace a sub-processor with shorter notice and will tell the Customer as soon as possible.

8. International transfers

8.1 Some sub-processors process data outside the EEA, as set out on the sub-processors page. The model provider (Anthropic) stores data and runs the analysis in the United States: KaizenProof restricts its processing to the United States on every request.

8.2 For each such transfer Capital AI relies on the Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914) as incorporated in the provider's data processing terms, and, where the recipient is certified, on the EU-US Data Privacy Framework.

8.3 Capital AI will tell the Customer if a transfer mechanism it relies on is invalidated, and will take reasonable steps to replace it.

9. Data-subject requests

9.1 If a data subject sends Capital AI a request about Customer Content, Capital AI will pass it to the Customer without undue delay and will not answer it itself unless the Customer instructs it to.

9.2 The product lets the Customer handle most requests itself: every member can read all workspace content; a friction's reporter (unless it is a standard) or any workspace owner can delete a friction, with its whys, countermeasures, check-ins, thanks and standard; the friction's owner or a workspace owner can revise its text and root cause; a person named in a credit can remove their name; a workspace owner can change the brand on templates or remove its logo (while the workspace is not read-only), download all workspace data, remove members and delete the workspace.

9.3 Former members. When a member leaves, is removed or deletes their account, their content stays in the workspace. It stays linked to their internal user id and is shown as "Former member". When the person deletes their account, Capital AI deletes their sign-in account, user record, preferences and invitations addressed to them. After that, nothing in Capital AI's systems links the user id to the person. Erasure of that person's content in the workspace is the Customer's decision, and Capital AI will help it.

Limits the Customer should know:

  • In the app, all former members appear as "Former member". A workspace owner cannot tell two former members apart, or list everything one of them wrote.
  • While the person's account still exists (for example after removal rather than account deletion), Capital AI can identify their content on request and tell the Customer which frictions, answers and check-ins it is.
  • After the person has deleted their account, Capital AI can no longer identify their content by name or email address. Only the text itself can show who wrote it.
  • Deletion works per friction. There is no way to delete one person's answers from a friction while keeping the rest.

9.4 Capital AI will provide further reasonable assistance on request, within the scope of section 4(e), at no charge.

10. Personal data breaches

10.1 Capital AI will notify the Customer without undue delay after becoming aware of a personal data breach affecting Customer personal data.

10.2 The notice will be sent by email to the workspace owners. It will describe, as far as known, the nature of the breach, the categories and approximate number of data subjects and records, the likely consequences, and the measures taken or proposed. Information not available at first will follow in phases.

10.3 Capital AI will not notify the Customer's data subjects or authority on the Customer's behalf unless the Customer asks it to or the law requires it.

11. Impact assessments and prior consultation

Capital AI will give the Customer the information it reasonably has about the processing (this DPA, the sub-processors page, Annex 2) to help with a data protection impact assessment or prior consultation.

12. End of the service: deletion and return

12.1 Return. At any time, including while the workspace is read-only, a workspace owner can download the workspace's data as a JSON file (Workspace screen): the workspace, its members, its brand on templates with the logo, and every friction with its whys, countermeasures, check-ins, "me too" entries, thanks and standard. The file does not include invitations or usage records. One file holds up to 2,000 frictions; a larger workspace cannot be downloaded in one file today.

12.2 Deletion. When a workspace owner deletes the workspace, Capital AI deletes all Customer Content in it from its database at once: frictions and their history, countermeasures, check-ins, standards, thanks and credits, members, invitations, the brand on templates with its logo, and usage records. There are no backups of the database. Copies held by sub-processors are deleted on their schedules: the model provider within 30 days of each request (longer only if its safety systems flag a request), as it states; Google within about 180 days through its deletion process; platform request logs after 30 days; copies of sent emails in Capital AI's mailbox when Capital AI deletes them.

12.3 When the trial ends, the workspace becomes read-only and nothing is deleted automatically. If Capital AI introduces a period after which read-only workspaces are deleted, it will publish it in the Terms before it applies.

12.4 Capital AI may keep Customer personal data after the end only where EU or member state law requires it, and then only for that purpose.

13. Audits and information

13.1 Capital AI will answer the Customer's reasonable written questions about its compliance with this DPA, and will provide this DPA, the sub-processors page, Annex 2 and relevant extracts of its records of processing. Capital AI does not hold security certifications or third-party audit reports.

13.2 If that information is not enough to show compliance, or a supervisory authority requires it, the Customer may ask for an audit. The audit will be carried out by the Customer or an independent auditor bound by confidentiality, on 30 days' notice, at the Customer's cost, no more than once a year, and without access to other customers' data or to the sub-processors' systems.

14. General

14.1 If this DPA and the Terms conflict on personal data, this DPA prevails.

14.2 Liability under this DPA is subject to the limits in section 16 of the Terms, except where the law does not allow it.

14.3 This DPA is governed by the law that governs the Terms (Italian law), and disputes go to the courts named there.

Annex 1: Details of the processing

Data subjects

  • Members of the Customer's workspace (usually the Customer's employees or contractors), including former members.
  • People invited to the workspace who have not joined.
  • People mentioned in workspace content: colleagues, managers, customers, suppliers or anyone else a member writes about.

Categories of personal data

  • Members: name and email address (shown to other members), internal user id, role, date joined, day last active, the frictions they reported or own, their answers to why questions, edits, rejection reasons, check-in answers and minutes saved, who confirmed each check-in, "me too" entries and their time figures, thanks given and received, credits on standards, invitations they sent.
  • Invitees: email address, inviter, workspace, dates, number of sends, state.
  • Workspace name. It may contain a person's name: by default it is built from the display name of the person who created it.
  • The brand on templates: a name, two colours, a logo image, and the internal user id of the workspace owner who last changed it. The name or the logo may be a person's own (a sole trader, for example); otherwise it is not personal data. It is not sent to the model provider.
  • Free text in frictions, answers and reasons, and model output derived from it. This may contain any personal data a member chooses to type. The Terms forbid special categories of data and data about criminal offences, but the product cannot prevent them.
  • Time figures (frequency, minutes each, minutes saved per week) that describe a member's own work.

Special categories: none intended. See above.

Frequency: continuous, while the workspace exists.

Processing locations: database in Google Cloud europe-west1 (Belgium), application in europe-west4 (Netherlands); sub-processors as on the sub-processors page.

Retention: until deleted by the Customer or its members, or by the workspace's deletion; usage records 90 days. See section 12.

Annex 2: Security measures, as they are today

Only what the code and configuration do today.

Tenant isolation

  • The browser has no direct access to the database. The Firestore security rules deny every client read and write, for every document.
  • Every API request is authenticated with a Firebase ID token. The server works out the caller's workspace from their membership record, never from the request. A request for another workspace's item returns "not found".
  • Access ends when the membership record is deleted, at the member's next request. A role change takes effect at the next request.
  • The code repository contains automated tests for the database rules, for cross-workspace access attempts and for deletion.

Least privilege inside a workspace

  • Only a friction's owner or a workspace owner can change it. Only its reporter or a workspace owner can delete it. Only workspace owners can invite, remove, change roles, export or delete the workspace.
  • A workspace always keeps at least one owner.

Authentication

  • Sign-in with Google or an email link only. A workspace is created only for a verified email address.
  • Deleting an account or a workspace needs a sign-in less than 5 minutes old and typing the email address or workspace name.
  • Invitations are bound to the invited address. The link holds only a random 160-bit identifier, which grants nothing by itself. Accepting needs a verified sign-in as that address and a click; following the link does nothing on its own.

Encryption

  • In transit: HTTPS, with HTTP Strict Transport Security.
  • At rest: Google Cloud's default encryption.

Handling of untrusted text

  • What users type is sent to the model inside delimiters and never placed in the model's instructions. Model output is checked against a schema and shown as text, never inserted into the page as HTML.
  • Customer text is never placed in an email subject. Workspace names cannot contain links or addresses.
  • A logo is accepted only as a PNG image of at most 256 KB and 2,000 pixels a side. The server checks the file's structure and stores a rewritten copy without its metadata; other formats, including SVG, are refused. It is served only to the workspace's members, as an image. The brand name and colours are written into generated files as text and as six-digit colour codes, never as markup.

Abuse and cost limits

  • Request-rate limits per user, with a lower limit on generating files and uploading a logo; daily caps on frictions, invitations, exports and new trial workspaces; a daily model-token budget per workspace and a product-wide ceiling.

Logging

  • Application logs hold ids and counts. They do not hold workspace text or email addresses. Request bodies are not logged.
  • The platform's request logs (IP address, browser, URL) are kept by Google Cloud for 30 days.

Secrets

  • No secret is stored in the code repository. Secrets are held in Google Secret Manager and given to the application at run time only.

Deletion

  • Hard deletes, with no backup. Workspace deletion removes every collection under the workspace, including collections added in future. Usage records carry an expiry and are deleted automatically after 90 days. A scheduled job runs once a day: it finishes any interrupted workspace or account deletion and removes records past their retention period.

What is not in place, stated so that nobody assumes it

No security certification; no penetration test; no single sign-on; no audit log of member or staff actions; no access log or approval step for Capital AI staff access to the database; no backups.