Privacy Policy
Checkrail Tecnologia Ltda.
1. Who we are and what this policy covers
Checkrail Tecnologia Ltda. (“Checkrail”, “we”, “us”) provides an HTTP API that engineering teams call from their coding-agent pipelines to review a pull request: it fetches the pull request's diff and changed files from the customer's code host, reads them against the task the agent was given, posts review comments on the pull request and returns its findings to the customer as structured data, billed per review.
Registered at Rua Marechal Deodoro 630, Sala 1204, Centro, 80010-010 Curitiba, Brazil.
We handle personal data in two different situations, and different rules apply to each:
| Whose data | Our role | What applies | |
|---|---|---|---|
| Part A | People who visit this website, ask about the service or write to us | Controller: we decide why and how the data is used | This policy |
| Part B | People whose names, usernames and email addresses appear in the pull requests, commits, code and tickets a customer's pipeline sends us for review, such as commit authors, reviewers and ticket assignees, and the customer's own staff who hold API keys | Set out in B.1, because it depends on the data | This policy and the data processing agreement we sign with each customer |
If the data processing agreement (“DPA”) and this policy ever disagree about Part B, the DPA wins.
2. Part A: this website and our contact with you
This part covers the personal data we collect for our own purposes: running this website, answering requests, and staying in touch with people who are or might become customers.
A.1 What we collect
What you give us. When you send the form on this site, we collect what you type into it, such as your name, email address, phone number or company, and the fact that you agreed to be contacted. If you email or talk to us, we keep that correspondence and any contact details in it.
What is collected automatically. Our web server records the IP address a request came from, the browser used, the pages requested, the page you came from and the time. These logs exist to keep the site running and secure.
We don’t ask for sensitive data (the “special categories” in Article 9 GDPR) through this website, so please don’t send any through the form.
A.2 Why we use it, and what allows us to
| Why | What | Legal basis (GDPR Art. 6) |
|---|---|---|
| Answering your request and working out whether the service fits | What you sent in the form, our correspondence | Art. 6(1)(b): steps you asked for before a contract |
| Looking after customers, billing and support | Contact details, correspondence | Art. 6(1)(b): carrying out a contract |
| Keeping the site running, secure and free of abuse | Server logs | Art. 6(1)(f): our legitimate interest in running a secure service |
| Contacting you about the service | Email address, company | Art. 6(1)(f): our legitimate interest in business-to-business marketing. You can object at any time |
| Meeting tax, accounting and legal duties | Billing and contract records | Art. 6(1)(c): a legal obligation |
Where we rely on legitimate interest, we have weighed that interest against your rights, and you can ask to see the assessment.
A.3 How long we keep it
- Requests from people who don’t become customers: 12 months from our last contact, then deleted.
- Customer contact and contract records: for the length of the agreement plus five years, the period Brazilian tax law sets for tax records.
- Server logs: 30 days.
- A record that you objected or opted out: kept indefinitely, so we can keep respecting it.
A.4 Your rights
If you are in the EEA or the UK, you can ask to see your data, correct it, have it deleted, limit or object to how we use it, get a copy you can take elsewhere, and withdraw consent where we rely on it. Write to [email protected] and we will answer within one month.
You can also complain to a data protection authority. If you are in the EEA, that can be the authority where you live or work.
3. Part B: data inside the service
Our customers are software companies and the engineering teams inside them. When a customer's pipeline asks for a review, we fetch the pull request's diff and the files it changes from the customer's code host, and the ticket text from its issue tracker if the call names one. We hold them while the review runs and keep the findings for the customer to fetch. This part explains what we read, what we keep, and where it is kept.
B.1 What we handle, and in what role
For everything we fetch to perform a review we act as a processor: the customer decides which repositories the app is installed on, which pull requests are sent for review, and whether its labeled pairs are contributed to the shared code model. For the accounts of the customer's staff and the billing record we act as a controller. Inside the service we handle:
- Pull request content. The diff of each pull request sent for review, the full text of every file it changes at the head commit, the pull request title and description, commit messages, and the usernames and email addresses of commit authors and reviewers that the code host returns with them.
- Surrounding code. Files that call a function the diff changes, fetched at review time from the default branch, and an index of each installed repository built from embeddings of its files, held with file paths and line ranges but without the code text.
- Task text. The title and body of the Linear or Jira issue named in a call, fetched through a read-only token the customer grants, or the prompt text the customer's pipeline sends in its place, including any names and comments the issue carries.
- Reviewer outcomes. Whether each comment we posted was resolved by a later commit, dismissed or answered, and by which username, stored with the finding as a labeled pair.
- Account, keys and usage. The work email given when a key is issued, the repositories the app is installed on, each key and its spend cap, and a usage record of every review: repository, pull request number, head commit, changed lines counted, findings posted, held and discarded, and whether it was billed.
We do not receive the customer's code-host passwords, deploy keys or secrets store. The code-host app is granted read access to repository contents and pull requests and write access to pull request comments, and nothing else; it cannot approve, merge, push or change a branch protection rule.
We do not run the customer's code, tests or builds, and we read no repository the app is not installed on. A secret found in a diff is reported by its file and line; its value is not copied into a finding, a log or a labeled pair.
B.2 What we do with it
Storage. Diffs, fetched files, task text, findings, repository indexes and labeled pairs are stored encrypted on cloud infrastructure in Frankfurt, each account under its own key and not readable from another account.
Review. The fixed checks, the embedding model, the code model and each account's reranker all run on cloud GPU capacity we control in Frankfurt. No diff, file, ticket or finding is sent to an outside model provider.
Repository index. For each installed repository we keep an index of embeddings of its files at the default branch, with paths and line ranges but no code text, updated when the default branch changes. It is used only within that customer's account and deleted when the app is removed from the repository.
Model training. Labeled pairs train only the reranker of the account they came from. If an account owner opts in, that account's pairs (the finding, the hunk it points at and the reviewer's verdict) are also used to fine-tune the shared code model, on the same cloud GPU capacity we control in Frankfurt. An account that has not opted in contributes nothing.
Staff access. Our staff open a customer's reviews only to resolve a support request the customer raised, only for the review named in it, and every such access is written to an access log the customer can fetch through the API.
B.3 AI models: where they run and what they learn from
Where models run. Three kinds of model run inside the service: an embedding model that indexes each installed repository and finds the callers of changed code; an open-weight code model that reads each changed hunk with its whole file, those callers and the task text, and proposes findings; and a reranker per account that scores each finding's confidence. All of them are served on cloud GPU capacity we control in Frankfurt, beside the data, which is stored on cloud infrastructure in Frankfurt. No diff, file, ticket or finding is sent by us to an outside model provider, and no model provider is a sub-processor of the service.
Training. We do not train models on your source code, diffs or tickets. The one exception is the labeled-pair corpus: when a reviewer resolves or dismisses a comment we posted, we store the finding, the hunk it points at and the reviewer's verdict as a pair, and nothing else from the pull request. Inside an account those pairs belong to the customer, retrain that account's reranker nightly and are not shared between customers. The shared code model is fine-tuned on pairs only from accounts whose owner opts in; the opt-in is off by default and can be withdrawn for future training. The code model in service today is an open-weight model prompted by us and trained on no customer data. Opted-in pairs are the training set for the fine-tuned model planned for March 2027, trained on the same cloud GPU capacity we control in Frankfurt, which contributed pairs do not leave.
Where a person decides. The models propose and your reviewers decide. A finding scored at 0.80 or above is posted as a comment; a finding between 0.50 and 0.80 is returned to your software in a held list and never posted; a finding below 0.50 is counted and discarded. Fixed checks are posted whatever the score, and a secret, a CI configuration change or a path owned by another team routes the pull request to a person first. The service cannot approve, block or merge a pull request: the approval your code host requires is given by a person at your company. No output of the service is an automated decision with legal or similarly significant effect on any individual; it comments on code and takes no decision about the people who wrote or reviewed it.
B.4 Where the data is kept
All data inside the service is stored and processed on cloud infrastructure in Frankfurt, Germany, and every model runs on cloud GPU capacity we control in Frankfurt. We keep no copy outside the European Union and we offer no other location today.
Customers in the United States and elsewhere outside the European Union should note that a review means the diff, the changed files and the task text are transferred to and held in Germany for the retention periods below. There is no version of the service installed inside a customer's own network.
The suppliers that handle data in the service are named on our subprocessor list, which comes with the data processing agreement and which we send to anyone who asks: write to [email protected].
B.5 How long we keep it, and what deleting can’t remove
Fetched files and the full diff are deleted when a review completes; the hunks a finding points at are kept with the finding. Findings, the routing verdict and the task text are kept for 90 days and can be fetched through the API within that period, and a customer can delete a review earlier.
Labeled pairs are kept for the life of the account, because each account's reranker is trained from them. A repository index is deleted when the app is removed from that repository. The usage record of each review, without code or task text, is kept for five years after the end of the year it was billed in, the period Brazil's National Tax Code gives the tax authority to review the invoices it supports.
When an account is closed, its findings and labeled pairs can be exported as JSON for 30 days. After that everything in the account is deleted, and backups roll off within a further 35 days.
B.6 Requests from people whose data is in the service
The customer is the controller of the names, usernames and email addresses in its repositories, pull requests and tickets. If a commit author, a reviewer or a person named in a ticket asks us about their data, we pass the request to the customer within five business days and do not answer it ourselves. A customer can list every review of a pull request through the API and delete any of them at any time.
For everyone
4. Moving data between countries
Checkrail Tecnologia Ltda. is a company in Brazil, outside the EEA, and handles personal data under Brazil’s LGPD (Law 13.709/2018) and, where it applies, the GDPR. Section B.4 says where the data in the service is kept. When personal data from the EEA or the UK reaches us, for example because someone there writes to us or a customer there uses the service, it is protected by the European Commission’s Standard Contractual Clauses and the technical measures described in our security documentation. You can ask us for a copy. In Brazil you can complain to the ANPD, Brazil’s data protection authority.
EU representative (Article 27 GDPR). Write to [email protected] with “EU representative” in the subject line and we will send you our representative’s details.
5. Security
We protect data in line with the risk. That includes encryption in transit and at rest, access limited to the people and systems that need it, each customer’s data kept separate from every other’s, and a log of every access to production systems.
If a personal data breach affects you, we tell you without undue delay, and at the latest within 36 hours of finding out, with the information you need to meet your own reporting duties.
6. Children
The service is sold to businesses and is not meant for children. We don’t knowingly collect personal data from anyone under 16.
7. Changes to this policy
We may update this policy. If a change matters, we email customers at least 30 days before it takes effect. The version number and date at the top of this page change every time.
8. Contact
Privacy questions and anything else: [email protected]
By post: Checkrail Tecnologia Ltda., Rua Marechal Deodoro 630, Sala 1204, Centro, 80010-010 Curitiba, Brazil