Beevelop UG (haftungsbeschränkt) · Amtsgericht Stuttgart HRB 765497 · Dobel, Germany
Every claim here is checkable.
An unfamiliar supplier in your production systems is a risk you carry by name. That is fair, so everything your data-protection officer, your procurement desk and your AI file will ask for is below.
Access is yours to grant.
You create the account, you set its scope, and you remove it when the engagement ends.
You create the account we work under, and you choose what it can reach. Narrow it whenever you like; you do not have to ask us first. Removing the account ends the access, because the account was yours from the start.
The same account holds the CI that builds your product, and the cloud bill is yours. Everything the engagement touches sits inside accounts you already control.
Granted. An account you create, under the name you choose.
Scoped. Only what one engagement needs, and nothing wider by default.
Revoked. Removed by you, the same way you would remove anyone else.
Nothing is taken back.
The code, the documentation and the running system are already yours before the engagement ends.
The repository sits in your own organisation from the first commit, and the CI that builds it runs in your account. What we add joins code you already own.
So there is nothing to hand over at the end, and nothing to export. You hold the work the way you would if your own engineers had written it.
Licence terms for one piece of work, including anything the pipeline drafted, are settled in that engagement's own agreement.
The ruling stays human.
Your source code reaches a model provider, and a person of yours decides what merges.
An agent pipeline drafts a change, reviews it, and runs the test suite. What it produces is a proposal, and the decision to merge is a person's.
Automated gates run on every proposal, in your CI and under your account. A failing check blocks the merge rather than logging a warning and continuing, and no gate can be skipped.
Your source code is what the model sees.
An agent pipeline works by sending source code and the surrounding context to a model provider's API. That is the mechanism, and there is no honest version of it where the repository stays sealed. So your data-protection officer is asking the right question: which provider, where, and on what terms.
One thing holds whatever the answer is. The pipeline opens pull requests; it merges nothing, and it decides nothing about a person.
Your subprocessor list is the one in your contract.
No supplier's website finishes an Art. 28 agreement or an Art. 44 transfer assessment, and this one does not try. Your file needs three things: the recipient, the place of processing, and the instrument that carries a transfer out of the EEA.
All three are settled in the engagement's own agreement, with you, before the pipeline runs. There is no standing list to publish, because no list binds until it is written into one agreement.
That much you can verify yourself. The pipeline runs in your CI, so every call leaves from your own network, and your egress log records the host it reached.
Your AI file needs a description, not a certificate.
- What the system does
Drafts code changes in your repository and opens them for review.
- Where it runs
Your continuous integration, under an account you created.
- What it reads
The repository it is working in, and the context of the change it was asked to make.
- What it decides
What to propose. A person decides what merges.
- Who operates it
We do, on your behalf, inside accounts you control.
Art. 4 KI-VO has applied since 2 February 2025, and it reaches anyone operating an AI system on your behalf. A pipeline running in your CI is exactly that. Your file classifies the system; our part is to describe it accurately enough for you to do so.
Those five rows are the description. These are the documents that carry it, and where each one comes from.
- Auftragsverarbeitungsvertrag, its TOM annex and the subprocessor list
You get all three at contracting, under Art. 28 and Art. 32 GDPR.
- NIS2 supplier questionnaire
Send it. Everything that holds regardless of your environment is answered above; the rest follows from the accounts you create.
- Entry for your AI file, Art. 4 KI-VO
The five-row description is written to be pasted into one.
- ISO 27001 or SOC 2 certificate
There is none. What runs in its place is the next section.
Checked, not certified.
There is no ISO 27001 or SOC 2 certificate. What replaces one is published and repeatable.
Signed images, an SBOM and provenance on every container buildgithub.com
CI gates that fail the build rather than warndocker.yml
Image tags are dated and never deleted, so a build stays reproduciblehub.docker.com
None of that is a substitute for an audit; it is what stands in front of one, and it is running today rather than promised.
We build to WCAG 2.2 AA.
It is a floor rather than a target, and the check runs on the commit that would break it.
The BFSG has been enforceable since 28 June 2025, and it reaches services sold to consumers. A shop, a banking service, ticketing, e-books, telecommunications: if your product is one of those, it is in scope. The standard your auditor will name is EN 301 549.
Retrofitting conformance after launch costs more than building to it, and the deadline for that argument has already passed. So the check belongs in the pipeline, beside the tests, on the change that introduces the defect.
Automated coverage is not the whole of conformance, and we do not present it as one. A machine finds contrast, structure and naming; a person reads for the rest.
The entity, on the record.
Everything below is transferred from the legal notice, not restated from memory.
- Legal name
- Beevelop UG (haftungsbeschränkt)
- Registered seat
- Dobel, Germany
- Register court
- Amtsgericht Stuttgart
- Register number
- HRB 765497
- VAT ID
- DE319750960
The managing director's name and the postal address are in the legal notice.
Answered before you ask.
Who can reach our systems?
Nobody by default. Access starts with an account you create under your own name, scoped to what one engagement needs.
Does our source code go to a model provider?
Yes. That is how an agent pipeline works, and the alternative is not having one. Whether a provider trains on what it processes is a term of that provider's contract. The one that binds an engagement is agreed with you before the pipeline runs.
Which subprocessors process our code?
They are named in your engagement's Auftragsverarbeitungsvertrag, and you agree it before anything runs. It carries the processing location and the transfer basis an Art. 44 assessment needs.
Who reviews what the pipeline writes?
You do, under your own review process, before anything merges. The gates run first, so a broken change never reaches that review.
Who owns the code once it ships?
You do, from the first commit. It is written in your repositories under your organisation, so ownership never changes hands.
Are you ISO 27001 or SOC 2 certified?
No. Signed images, a software bill of materials and provenance attestation ship on every container build. A failing gate stops a change rather than filing a warning against it.
What does your CI need from us?
An account, a repository and a runner, each created by you. Scope them to one engagement, and remove them when it ends.
Where is your privacy notice?
In the legal set, in German and English, with the German text binding. It names what the host records and what rights you have over it.
How does an engagement end?
You remove the accounts you created, and the running system and its documentation stay in your own infrastructure. There is no renewal to arrange, because there was no retainer to begin with.
Tell us what is in the way.
Say what you're building and where it stopped.
hello@beevelop.comCopy it into your mail client if that is easier.
The draft opens with
- What you are building
- What is in the way
- The stack
- When you want to start
The contact page says who answers, and what the reply contains.