Data Processing Agreement

What this agreement is

This is the agreement Article 28(3) of Regulation (EU) 2016/679 (the GDPR) requires between a controller and its processor. It applies whenever a studio uses ArquiFlow to hold or work on personal data about other people — its clients, the people at a site visit, the people in a photograph. For that data the studio is the controller and ArquiFlow is the processor.

For the data that makes you an account holder — your name, your sign-in, your studio membership, your subscription — ArquiFlow is itself the controller, and the privacy policy covers it rather than this page.

It is concluded by using the service: it forms part of the terms of service and needs no signature. A studio that needs a signed copy asks at architectureminutes@gmail.com and we send one signed on our side.

It runs for as long as the studio uses the service. It begins the first time the studio uploads anything about another person, and the processing ends when the material is erased or returned, as the termination section below describes.

This agreement is published in English, Spanish and Catalan. The Spanish version is the authoritative one; the other two are translations offered for convenience.

Subject matter, nature and purpose of the processing

The subject matter is the production of an acta — a site-work report, an inspection visit, a meeting, a safety or quality report, an ITE/IEE, an expert opinion or a change request — from what a studio uploads about one of its projects, together with the project work around it: estimates, plans, supplier quotes, and questions asked of a project’s own documents.

These are the operations ArquiFlow carries out on the studio’s material.

• Storing what the studio uploads, and what the service produces from it.
• Transcribing a recording of a site visit or a meeting.
• Describing a site photograph and placing it in the acta.
• Drafting the text of the acta and generating the PDF the studio issues.
• Sending the issued PDF to the parties the studio names on it.
• Extracting the text of an uploaded plan, technical document or supplier quote, and comparing quotes.
• Indexing an issued acta and answering questions asked over a project’s own documents.
• Looking up the cadastral reference of an address the studio types.

ArquiFlow performs them for the studio and for no purpose of its own. Nothing a studio uploads is sold or made visible to another studio: every read is scoped to the studio that owns the row, and that scope is enforced underneath the features rather than left to each of them.

Categories of personal data and of data subjects

The categories are whatever the studio puts into the service. In practice they are these.

• Identifying and contact data — names, roles, telephone numbers and email addresses, in a report, in a request to sign one, or in a plan, technical document or supplier quote.
• Voice — the recording of a site visit or a meeting and the transcript made from it, which carry whatever was said and whoever said it.
• Images — site photographs, which can show the people who were on site, and the descriptions written from them.
• Location — the address of a site and the cadastral reference looked up from it, which identifies a property and through it, often, whoever owns it.
• Free text — everything else the studio writes or uploads: findings, decisions, instructions, incidents.

And the people the data is about.

• The studio’s clients and the people who work for them.
• Owners, occupiers and neighbours named in a report.
• The people present at a site visit or a meeting whose voice the recording carries.
• The people visible in a site photograph.
• The contact people at a supplier whose quote the studio uploads.
• Anyone else the studio names in something it uploads.

The service is not built for the special categories of data in Article 9 GDPR — health, trade-union membership, biometric data used to identify someone — and a studio must not enter them. A recording of a site visit is voice, not a biometric identifier: nothing in the service measures a voice in order to recognise a person.

Processing only on the studio’s instructions — Art. 28(3)(a)

ArquiFlow processes the data only on the studio’s documented instructions, including as regards a transfer to a third country. The documented instructions are this agreement, the terms of service, and the studio’s own use of the features: uploading a recording is the instruction to transcribe it, issuing an acta is the instruction to generate its PDF and send it to the parties named on it, and asking a question of a project is the instruction to search that project.

There is no other instruction channel and none is needed. A studio that wants something outside them writes to architectureminutes@gmail.com, and what we agree is documented in that exchange.

If we believe an instruction breaks EU or Spanish data-protection law, we say so and do not carry it out. Where EU or Spanish law obliges us to process the data for a reason of its own, we tell the studio before we do it unless the law itself forbids telling it.

Confidentiality — Art. 28(3)(b)

Everyone with access to the data is bound to keep it confidential, and that obligation outlives their work on the service.

Access to production data is limited to the people who operate the service, is exercised through an administrative connection to the single server described below, and is used to keep the service running. Nobody at ArquiFlow reads a studio’s recording, report or document except where the studio asks in writing for help with a specific one, or where the law obliges us to.

Security measures — Art. 28(3)(c) and Art. 32(1)

These are the measures in place. They are described so that a studio can judge them, rather than summarised as an assurance.

• Traffic between a browser and the service travels over TLS, on a certificate issued and renewed automatically at the edge.
• Passwords are stored as a one-way hash and never in readable form. A signed-in session is carried by cookies that JavaScript in the browser cannot read and that, in production, are sent over HTTPS only.
• Each studio’s rows are separated in the database by a filter applied to the queries that read them, which matches no row at all when no studio is in scope — so a query that forgets to name a studio returns nothing rather than everything.
• Files live in a private object store, under keys the server generates rather than keys a client can guess. A file is served through the application, which checks which studio it belongs to first, and never from a public address.
• What a member may do inside a studio follows the role the studio gave them, re-checked on the server for every action rather than only hidden in the interface.
• Our own record of an AI call holds a digest — which model, which task, timings, token counts and a hash — and not the transcript or the document text. A test enforces that.

What is not in place yet: there is no scheduled database backup, so the ability to restore the data after a hardware failure rests on the hosting provider’s own infrastructure and not on a copy we hold. It is named in the operations checklist as something to add, and this section changes when it is added. A studio is better off knowing that than assuming otherwise.

Subprocessors — Art. 28(2), Art. 28(3)(d) and Art. 28(4)

The studio gives general written authorisation, under Article 28(2) GDPR, for ArquiFlow to engage the subprocessors listed here. Each is engaged under a contract imposing the same data-protection obligations this agreement imposes on ArquiFlow, as Article 28(4) GDPR requires, and ArquiFlow answers to the studio for what a subprocessor does. The last column links to each provider’s own terms, because where a company processes data is a fact about that company and we will not assert it on its behalf.

We tell studios by email at least 30 days before a subprocessor is added or replaced. A studio that objects on reasonable data-protection grounds says so within that period, and where we cannot offer it an alternative it may end its subscription with nothing further to pay.

The server host is the row a list like this most often leaves out and least can afford to: every category above passes through it. Its jurisdiction is stated as to be confirmed, and it is filled in — here, in the same table — before the service takes its first live payment.

Transfers outside the European Economic Area — Art. 46(2)(c)

Some of the subprocessors above are outside the EEA, and the studio’s general authorisation covers those transfers. This is what each one rests on.

• The United States — Groq, OpenAI, Google and Paddle’s US operations. OpenAI also receives the content DeepSeek receives, for a request DeepSeek does not answer. The safeguard is the European Commission’s standard contractual clauses under Article 46(2)(c) GDPR, incorporated in each provider’s data processing terms; where a provider is certified under the EU–US Data Privacy Framework, that certification applies instead.
• China — DeepSeek, which receives transcripts, report text, building-code questions, supplier-quote text and dictated incidents. The European Commission has adopted no adequacy decision for China, so the transfer rests on standard contractual clauses under Article 46(2)(c) GDPR. We say plainly that what those clauses achieve in practice may be weaker than inside the EEA.

A studio that cannot accept a transfer to CN cannot use transcription and drafting as they are built today: there is no EEA-only mode to switch to. That is worth reading before a recording is uploaded rather than after, because the studio chooses what goes into a recording or a document in the first place.

Ask us at architectureminutes@gmail.com for the safeguard relied on for any single provider, and we send what we hold.

Helping with a data subject’s request — Art. 28(3)(e)

If someone whose data a studio uploaded exercises a right — access, rectification, erasure, restriction of processing, objection or portability — the studio answers them: the studio is the controller and holds the relationship. ArquiFlow assists, taking into account the nature of the processing, so the studio can answer within the month Article 12(3) GDPR allows it.

The assistance is given by hand. Write to architectureminutes@gmail.com from an address on the studio’s account, name the project and the person, and say what the request asks for. We find the material, tell the studio where it is — a recording, a transcript, an acta, a photograph, an index entry — and then either erase it or send the studio a copy of it, within ten working days of a clear request, which leaves the studio the rest of its month.

There is no button for this. The service has no self-service mechanism for access, erasure or portability, and rather than imply one exists we say plainly that a written request is the only route and that a person answers it.

If a data subject writes to us directly, we do not answer for the studio: we tell them to contact the studio, and we tell the studio it happened, unless the law requires otherwise.

Security, breaches and impact assessments — Art. 28(3)(f)

ArquiFlow assists the studio in meeting its own obligations under Articles 32 to 36 GDPR, given the nature of the processing and what we hold.

• A personal data breach — we notify the studio without undue delay after becoming aware of one, as Article 33(2) GDPR requires, with what we know: what happened, which categories and roughly how many people and records are involved, the likely consequences, and what we are doing about it. Whether the AEPD or the people affected are notified is the studio’s decision, and we give it what it needs to take it.
• A data protection impact assessment — we answer written questions about how the processing works, what goes where, and on what safeguard, so the studio can carry one out. A studio that records people who do not know this service exists is the case for doing one.
• Prior consultation with a supervisory authority — we provide the same information.

None of this makes ArquiFlow the studio’s data protection officer, and none of it is legal advice.

Erasure or return when the processing ends — Art. 28(3)(g)

When the service ends — the studio closes its account, or its subscription lapses — the studio chooses: we erase what it uploaded and what the service produced from it, or we send it a copy back and then erase it. Ask at architectureminutes@gmail.com and we do it within 30 days of a clear request.

Until that request arrives, the material stays where it is. This is the clause an agreement like this usually writes as though it happened by itself, and here it does not: no scheduled job erases anything, closing an account marks it closed and leaves the studio’s actas, photographs, plans and files in place, and a transcript outlives the recording it came from. The one automatic expiry in the whole system is a one-hour cache of answers to building-code questions.

So a studio that wants the material gone has to ask — and asking is enough. We keep afterwards only what EU or Spanish law obliges us to keep: the accounting and tax records behind the subscription, which are account data and belong to the privacy policy rather than to this agreement.

Information and audit — Art. 28(3)(h)

ArquiFlow makes available the information needed to show that this agreement is being met, and submits to audits and inspections by the studio or by an auditor it mandates.

In practice that is written questions answered in writing, and this page: each section names the files in our own source tree that back what it says, and a test resolves every one of those paths and fails the build when one of them moves.

An audit that reaches the systems themselves is arranged in advance, at a reasonable time, under confidentiality, and no more than once a year unless a breach or a supervisory authority’s request makes another one necessary. It cannot extend to another studio’s data, which is the one thing we refuse.

One boundary worth naming: removing a member

A studio administrator can remove a member from the studio. That does two things at once: it ends the membership, and it closes that person’s whole platform account — not only their access to that one studio.

It belongs in this agreement because it is the one place where an instruction from the controller reaches a data subject for whom ArquiFlow is itself the controller: the account holder. We carry it out, because the studio decides who is on its team; what the person affected can do about their own account is in the privacy policy. An administrator who only means to end someone’s access to one project should know that this is what the action does.

Changes to this agreement

The date at the top of this page is the day it last changed. A change that affects a studio’s obligations, or the list of subprocessors, is announced by email before it takes effect. A change that only makes the same thing clearer is published here.

Anything about this agreement, including a request for a copy signed on our side, goes to architectureminutes@gmail.com.