Privacy Policy
Last updated: August 2026
1. Who we are
OperantLab is a software system for operant conditioning experiments, developed and sold by OperantLab Psicologia e Software Ltda to laboratories at higher-education institutions. The product is delivered in three forms: the desktop application installed on the institution's machines, OperantLab Mini (online data collection) and the corporate website www.operantlab.com.br.
- Legal name: OperantLab Psicologia e Software Ltda
- Company ID (CNPJ): 66.432.976/0001-41
- Address: R. Francisco Lindner, 534 — Centro, Joaçaba/SC, Brazil — ZIP 89.600-000
- E-mail: operantlab@operantlab.com.br
- Data Protection Officer (DPO): Marcos Alexandre Aragone de Medeiros — operantlab@operantlab.com.br
2. Who controls what
This is the most important distinction in this document.
- OperantLab is the controller of commercial contact data (anyone who writes to us through the website or WhatsApp), of the client institution's registration data and of the technical licensing data of each machine.
- The contracting institution is the controller of everything related to the experiments: who takes part, under what identification, which data is recorded and how long it is kept. In these flows OperantLab acts as processor, handling data only according to the institution's instructions and within the limits of the license agreement.
It is up to the institution to obtain consent, submit protocols to its ethics committee where applicable and instruct teachers and researchers on how participants are identified.
3. Data collected on the website
Through the contact form, WhatsApp or e-mail, we may receive:
- Name
- E-mail address
- Phone / WhatsApp number
- Institution name
- The message or question sent
This data is used solely to answer the request, to send information about OperantLab when asked and to prepare commercial proposals. We do not send unsolicited advertising.
The website uses no tracking cookies, advertising pixels or web analytics tools.
Legal basis: legitimate interest of the individual who contacts us spontaneously (art. 7, IX of Brazilian Law 13.709/2018 — LGPD) and, where applicable, consent (art. 7, I).
4. Client institution data
To perform the agreement we process: legal name, company ID, address, legal representative details, contact e-mails of the coordinator and of the technical officer, campus and the data required for invoicing.
Legal basis: performance of a contract (art. 7, V) and compliance with legal and tax obligations (art. 7, II).
5. Data processed by the installed application
Three of the features below — session history and CSV backup (items 5.3 and 5.4), sending results by e-mail (item 5.5) and usage statistics (item 5.6) — are, at licensed institutions, institution-wide decisions: set once by the plan's Responsible Professor, for the whole institution, and automatically propagated to every machine — no IT officer, teacher or student needs to decide individually on each computer. Every change is logged (who decided and when), as a transparency and accountability measure (art. 6, X, of the LGPD). During evaluation (trial), before a license is purchased, each feature keeps a simple per-machine control, since there is no institution yet to decide on its behalf.
5.1. Licensing and activation
To verify that an installation is licensed, the application sends the following to our servers:
- the machine hardware identifier (fingerprint, derived from the BIOS UUID and the processor identifier);
- the computer name (hostname) and the machine number within the plan;
- the institution and campus names;
- the software version and operating system;
- the date and time of the last access.
This data identifies equipment, not people. Even so, because a computer name may contain a user's name (for example, “PC-MARIA”), it is treated as personal data whenever that is the case. It is used to control the number of licenses in use, to release updates and to provide support.
Legal basis: performance of a contract (art. 7, V).
5.2. Experiment synchronisation between machines
Experiment configuration files (.oplab) exchanged between machines of the same institution are encrypted with AES-256-GCM (256-bit key, random nonce per file) before leaving the source machine. The key is randomly generated, unique per institution and stays on the institution's machines. A backup copy of the key is kept on our servers in encrypted form only, protected by a recovery code generated in the application and known only to the institution. Without that code, OperantLab has no technical means of accessing the key or the file contents.
Since August 2026, this key can also be transmitted directly between the institution's machines over the network — for example, when installing or reinstalling a machine that lacks the key. In this flow, the machine without the key generates a temporary key pair and sends our servers only its public key; a machine at the institution that already holds the key encrypts it specifically for that public key before sending it, and the server only relays this encrypted envelope, with no technical means of opening it. This only happens when: (i) whoever grants the key proves they hold it; (ii) the requesting machine has an active license at the institution; and (iii) the Responsible Professor opens, in the application, a time-limited authorization window.
5.3. Session history
At the end of each real experiment run (the teacher's pre-test is not recorded), the application stores a session summary on our server, so that teachers, researchers and students can look it up later from any machine of the institution:
- institution name, computer identifier and name, machine number;
- experiment name and environment (class or research);
- participant identification exactly as typed on the identification screen (fictitious name or participant code);
- start and end date and time, duration;
- totals of responses, errors and reinforcements, phase reached and whether the session was completed.
This data is not anonymous: the participant identification field is defined by whoever runs the experiment.
Recommendation to the institution: instruct teachers and researchers to identify participants by code (for example, P01, 2026-2-A-07) and never by their real name. Responsibility for the choice of identification lies with the institution, as controller.
Legal basis: performance of the license agreement entered into with the institution (art. 7, V), with OperantLab acting as processor on behalf of the controlling institution.
5.4. Cloud backup of session data (CSV files)
The raw results of each session are written to a CSV file on the machine itself, in the folder chosen by the institution.
In addition, the application keeps a backup copy of those files in our cloud so that the student can retrieve their data from another machine. In this transfer:
- the CSV content is encrypted with AES-256-GCM using the same institutional key described in 5.2 — the content is unreadable to OperantLab;
- the storage path contains the institution name, the participant identification and the experiment name unencrypted, so that the file can be located;
- files are automatically removed from the server after 1 (one) year.
This feature — which also governs the session history from item 5.3 — is disabled by default and is an institution-wide decision made by the Responsible Professor (see the note at the start of section 5). While off, no history or CSV is sent.
5.5. Sending results by e-mail
When a student, teacher or researcher asks for results to be sent by e-mail, we process the e-mail address provided (stored locally on the machine to make later sends easier) and transmit the message with the attached files through our own sending server and a transactional e-mail provider. Sending only happens on the user's explicit action.
This feature is enabled by default (preserving the product's long-standing behaviour) and can be disabled institution-wide by the Responsible Professor, for the whole institution (see the note at the start of section 5).
5.6. Anonymous usage statistics (optional)
The application has an optional usage statistics feature, disabled by default.
At licensed institutions, this decision is institution-wide (see the note at the start of section 5): the Responsible Professor sets it once for the whole institution, and no machine shows an individual accept/decline popup. During evaluation (trial), before purchase, each machine still shows the accept/decline choice once, on first launch — since there is no institution yet to decide on its behalf; the choice can be changed at any time in Settings. If declined or disabled, nothing is recorded or sent.
If accepted, the following events are recorded:
| Event | Content |
|---|---|
| Application opened | license type (trial or full) and days remaining |
| Application closed | license type and total usage time |
| Session started | environment (class/research), whether it is a pre-test, number of phases and figures, reinforcement schedules, license type, language |
| Session ended | same fields (except number of figures), duration in seconds and final score |
| Unexpected error | error type and short message (up to 300 characters) and the last line of the technical traceback |
Every event includes the software version, operating system, date and time in UTC and an 8-character code derived from the hardware — used only to group events from the same installation. These events contain no participant identification, experiment content or responses.
Legal basis: consent (art. 7, I) — given individually by whoever installs it, during evaluation, or collectively by the Responsible Professor on behalf of the institution, once licensed.
5.7. Local error log
The application keeps a technical log file on the machine itself with the last 500 lines of events and errors, for support diagnostics. This file is not sent automatically — it only reaches us if the technical officer attaches it to a support request.
6. OperantLab Mini (online data collection)
OperantLab Mini lets the institution run experiments over the internet. In it:
- the lead researcher registers a name and e-mail address to access the study dashboard;
- each participant is identified by the code or fictitious name defined by the researcher, and their progress and responses are stored on the study server;
- session data is protected by a key specific to the study, along the same lines as item 5.2.
The institution/researcher is the controller of this data and is responsible for recruitment, informed consent and ethics approval. OperantLab is the processor.
7. Sharing and service providers
We do not sell or transfer data. We share it only with providers necessary to run the service, all bound by confidentiality obligations:
| Provider | Purpose | Location |
|---|---|---|
| Supabase | database, storage of encrypted files and license authentication functions | Brazil (São Paulo, sa-east-1) |
| Locaweb | hosting of the website and of the OperantLab Mini server | Brazil |
| Transactional e-mail provider | sending of automated messages (results, activation codes, notices) | Abroad |
| GitHub | distribution of installers and software updates (no personal data) | Abroad |
We may also share data when required by a competent authority under a judicial or administrative order.
Where your data is kept. The database and file storage (including the session history and the experiment files and CSVs — the latter two always encrypted) are on servers in Brazil (Supabase, São Paulo region). The website and the OperantLab Mini server are also in Brazil (Locaweb). Experiment data does not leave the country under normal use.
International transfer. There are only two situations in which data passes through servers outside Brazil: (a) the transactional e-mail provider, when the user requests results to be sent by e-mail (recipient address and attachments); and (b) GitHub, which hosts the installers — with no personal data. In those cases, the transfer is made for the performance of the agreement entered into with the institution (art. 33, II, “d”, and IX of the LGPD). The institution may request an up-to-date list of providers and their processing locations at any time.
8. Security
- AES-256-GCM encryption of experiment files and of CSVs sent to the cloud, with an institutional key that never leaves the institution's machines.
- Transmission of the institutional key between machines, when needed, via an envelope encrypted specifically for the requesting machine (X25519 key exchange); the server never has access to the envelope's content.
- Profile passwords stored only as a SHA-256 hash and verified on the server: neither the application nor third parties can download the hashes.
- Row level security rules in the database, isolating each institution.
- Windows installers signed with an EV code signing certificate, guaranteeing the origin of the downloaded file.
- Server access restricted to OperantLab administrators, with credentials kept outside the source code.
9. How long we keep data
| Data | Retention |
|---|---|
| Messages and commercial contacts | for as long as the enquiry lasts; for clients, for the duration of the commercial relationship |
| Institution registration and tax data | the applicable legal period (up to 5 years after the end of the agreement) |
| Licensing data (fingerprint, hostname, accesses) | during the term of the agreement and for up to 12 months after it ends |
| CSV files in cloud storage | 1 year, removed automatically |
| Session history | during the term of the agreement; the institution may request deletion at any time |
| Anonymous usage events | indefinitely, as they do not allow identification |
Once the agreement ends, the institution has 30 days to export its files before the data held on our servers is deleted.
10. Your rights
Under the LGPD, data subjects may: confirm the existence of processing; access their data; correct incomplete or outdated data; request anonymisation, blocking or deletion of unnecessary data or data processed in breach of the law; request portability; obtain information about sharing; and withdraw consent.
Requests should be sent to operantlab@operantlab.com.br and are answered within 15 days.
If the request concerns experiment data (items 5.3, 5.4 and 6), the data subject should contact the educational institution, which is the controller of that data; OperantLab will act on any request forwarded to us by the institution.
11. Security incidents
Should a security incident occur that may pose relevant risk or harm to data subjects, OperantLab will notify the contracting institution within 2 (two) business days of becoming aware of it, describing the data affected and the measures taken, and will cooperate with the notification to the Brazilian data protection authority (ANPD) under art. 48 of the LGPD.
12. Children and adolescents
OperantLab is intended for higher education and scientific research. It is not directed at children. Where a research protocol involves minors, it is up to the institution to obtain specific and prominent consent from at least one parent or legal guardian, under art. 14 of the LGPD.
13. Changes to this policy
This policy may be updated from time to time; the date of the last update is always shown at the top. Material changes will be communicated to contracting institutions by e-mail.