Privacy Policy
Pirca sp. z o.o.
1. Who we are and what this policy covers
Pirca sp. z o.o. (“Pirca”, “we”, “us”) runs sealed cloud cells for software agencies, one cell for each client of the agency, where a coding model we fine-tune and serve ourselves works on that client's code. In a cell the model starts the client's application, does the tickets an engineer of the agency assigns, runs the client's tests and a browser check, and hands each change to an engineer of the agency, who decides whether it becomes a pull request in the client's repository. Every input the model reads and every output it writes is logged in the cell. This policy explains what personal data we handle when we do that, and why.
Registered at ul. Legnicka 48/6, 54-202 Wrocław, Poland.
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 | The agency's engineers and managers who hold accounts in our cells; the client's reviewers the agency invites to read a cell's log; and people whose names or contact details appear in a client's code, commit history or tickets | 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 after the close of the year in which their tax was payable, when the tax liability lapses (Articles 70 and 86 of Poland's Tax Ordinance).
- 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
This part covers the data that passes through a cell: the accounts of the agency's staff and of the client's reviewers, the client's repositories with their commit history, the tickets an engineer assigns, the keys the client issues, the seed data the model writes, and the cell's log of every model input and output.
B.1 What we handle, and in what role
For the accounts of the agency's staff and of the client's reviewers, and for billing, we are the controller under the EU's General Data Protection Regulation (GDPR). For everything inside a cell (the client's code and commit history, tickets, keys, seed data and the log) we act for the agency, which acts for its client: we are the agency's processor, bound by Article 28 of the GDPR and by our data processing agreement, and we use that data only to run that cell. The service handles the following:
- Accounts. The name and work email of each engineer and manager the agency adds, the one cell each engineer belongs to, when they sign in, and each yes, no, note and hand-over they give the model. The name and work email of each client reviewer the agency invites, and when they open the log.
- The client's repositories. The repositories the client's GitHub App lets the cell reach, with their commit history. Commits carry the names and email addresses of the people who wrote them, and code or fixtures can hold personal data the client put there.
- Tickets. The tickets an engineer assigns, read from one project in the client's Jira or Linear through a read-only connection, or typed into the cell: title, description and comments, which can name the people who wrote them.
- The cell's log. Every input the model reads and every output it writes, every command run, test result, screenshot and network request in the cell, and every action a person takes there, each with its time and its author.
We take no copy of a client's staging or production database. Seed data in a cell is written by the model from the client's schema, migrations and fixtures, with invented people on reserved test domains, and an engineer who finds real records in a fixture can mark the file so the model never reads it.
Key values the client issues, for repository access and for the test mode of the services its application calls, are stored encrypted in the cell. The model and the log see a key's name, never its value.
Nothing in a cell is sent to a third-party model provider, and no cell can reach another cell.
B.2 What we do with it
Starting the application. The model reads the client's repository inside the cell, writes the setup that starts the application, writes seed data and runs the client's tests on the untouched code, all on the cell's own machines on cloud infrastructure in N. Virginia. The setup stays in the cell and is never committed to the client's repository.
Doing a ticket. The model reads the ticket, the files an embedding model in the cell finds closest to it and the notes the cell's engineers keep, writes a change on a branch inside the cell, and runs the client's tests and a browser check. A second model grades the change. All three models run on a GPU inside that cell.
The pull request. Only when an engineer of the cell says yes does the cell push the branch to the client's repository with the client's own GitHub App and open a pull request, which names the model, the engineer who approved it and the log entries behind it.
The log. The log is kept in the cell and only added to, each entry carrying a hash of the one before it. The cell's engineers and the reviewers the agency invites can read and export it. The agency's managers see each cell's one-line status and its counts, not the log's contents.
No onward use. We never sell, share or reuse anything from a cell, never move it into another cell, and never use it to train or test any model, except a tuning of that client's own cell model which the client authorizes in writing and which stays in the cell. The subprocessors that host the cells on cloud infrastructure in N. Virginia, send our email and take payment are named on our subprocessor list.
B.3 AI models: where they run and what they learn from
Where models run. Three models run in the service, all open-weight models we serve ourselves inside each cell, on cloud GPU capacity we control in N. Virginia. The Pirca model, Devstral Small with weights we fine-tune, reads the client's repository, the ticket and the cell's notes, starts the client's application and writes changes. A code embedding model indexes the client's repository inside the cell so the Pirca model is handed the files closest to a ticket. The checker, a small model we fine-tune, reads the ticket, the change and the test results and grades whether the change does what the ticket asks. Each cell runs its own copy of the models on its own GPU, no cell's inputs reach another cell's models, and no input or output is sent to a third-party model provider, which is why none appears on our subprocessor list.
Training. We train no model on anything from a cell: not a client's code, commits, tickets, keys, seed data or log, not the changes the model wrote, and not the engineers' yes or no on them, whether for that client or pooled across clients. The Pirca model and the checker are fine-tuned only on tickets from public repositories whose licenses allow it (MIT, Apache or BSD), leaving out repositories that ask not to be used for AI training; on practice repositories Pirca's own engineers write and keep for that purpose; and on our reviewers' verdicts on the model's attempts there. Training runs on cloud GPU capacity we control in N. Virginia. From May 2027 a client may authorize in writing a tuning of its own cell's model on that client's merged pull requests; such a tuning runs on that cell's GPU, never leaves the cell, never reaches the shared models and is deleted with the cell. Without that written authorization, nothing from a cell is used for training.
Where a person decides. The model does tickets, and an engineer of the agency decides what reaches the client. The model never pushes to the client's repository, merges or answers a review comment; a pull request is opened only after an engineer of the cell reads the change, its tests and its log and says yes. The checker grades each change: when it is less than four in five sure the change does what the ticket asks, the change reaches the engineer marked unsure, with its reasons, never as ready, and an agency can raise that line for a cell but never lower it. A change that touches an area the cell has fenced off (sign-in, payments, migrations that drop or rewrite data, CI workflows, and any the engineers add) is stopped and handed back with a note, and a second failed test run ends the model's try. The service makes no automated decision with legal or similarly significant effect on any person.
B.4 Where the data is kept
Every cell, with the client's code, keys, seed data and log and the models that run in it, and each agency's accounts and list of cells, is stored and processed on cloud infrastructure in N. Virginia, in the United States. Pirca's staff work from Wrocław and open a cell only when the agency asks in writing, for that cell and a set time, and every such opening is written in that cell's log. Nothing from a cell is copied to Poland.
Under the GDPR the United States counts as adequate only for companies certified under the EU-US Data Privacy Framework. Personal data we hold as a controller, and personal data an agency in the European Union brings into a cell, reach N. Virginia under the standard contractual clauses the European Commission adopted in 2021 (Decision 2021/914), used without change. Payment details are held by our payment provider and never reach our systems.
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
A cell's contents (code, keys, seed data, branches and the log) are kept while the cell is open. When the agency closes a cell, we export the log with its hashes to the agency and to the client's reviewers, then delete the cell and every copy of it within 30 days, as Article 28 of the GDPR asks of a processor once the service ends. The agency receives a deletion record with the date.
If the agency and its client both ask in writing, we keep a closed cell's log, and nothing else from it, for up to two years before deleting it, the longest our data processing agreement allows.
Backups of a cell are encrypted with that cell's own key, kept on cloud infrastructure in N. Virginia for 14 days, and deleted with the cell.
Account details are kept for the life of the agency's account and 24 months after it closes. Invoices and the accounting records behind them are kept until the tax on them can no longer be claimed: five years after the end of the year its payment fell due, under Poland's Tax Ordinance. The corpus our models train on holds tickets from public repositories, our own practice repositories and our reviewers' verdicts on them, and nothing from any cell.
B.6 Requests from people whose data is in the service
If your name or details are in a client's code, commits or tickets, or in a cell's log, the agency and its client decide what happens to that data: we pass your request to the agency within five business days and act on its instruction. If you hold an account in a cell, as an engineer or as a reviewer, write to us directly. We answer every request without undue delay and at the latest within one month, the limit in Article 12 of the GDPR. You may also complain to Poland's data protection authority, the President of the Personal Data Protection Office (UODO).
For everyone
4. Moving data between countries
Pirca sp. z o.o. is a company in Poland, inside the EEA. Section B.4 says where the data in the service is kept. If any personal data we control ever has to leave the EEA, for example because a supplier named on our subprocessor list handles it elsewhere, it is protected by the European Commission’s Standard Contractual Clauses or another safeguard the GDPR accepts. You can ask us for a copy.
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: Pirca sp. z o.o., ul. Legnicka 48/6, 54-202 Wrocław, Poland