Our role under the AI Act, and our limits
Wire AI decides what each of your users sees next inside your app. That puts one set of duties on us and a different set on you. This page says which is which, in plain language, and where our answer is a position we hold rather than a settled question, it says that too. Nothing on this page is legal advice.
We are the provider. You are the deployer.
Wire AI is the provider of the Wire AI system. We build it and make it available to you as a limited-risk system: it personalizes and tests in-app experiences, and it is designed for that purpose only.
You are the deployer of the Wire AI surfaces that run inside your own app. You choose which surfaces to switch on, you decide what the goal of a flow is, you own the content and the audience, and you stay responsible for how those surfaces meet your users. The same split is written into the Roles section of the Terms, so it is a contract term and not a slogan.
Three signals Wire AI will not optimize on
Minor status and age. Health condition. Financial distress. Wire AI does not use signals of those three classes as optimization inputs, and your contract says you may not instruct it to. The long version, class by class, is in what Wire will not optimize on, and the binding version is the Acceptable Use section of the Terms.
Here is the part most pages leave out. Where an app's configuration carries an input of that class, the server observes it and writes a record. That is the whole behavior. The record is a log line on our side, it has no consumer today, and nothing in the product reads it back.
So the weight here is carried by the commitment and by your contract. Not by a machine. We would rather write that than describe something we have not built.
Wire AI is not to be changed into a high-risk system
Article 25(2) lets a provider specify that its AI system is not to be changed into a high-risk AI system. We specify exactly that. Wire AI is built for personalizing and testing in-app experiences and for nothing else, and adapting or integrating it so that it becomes a high-risk system is outside what you may do with it.
The Acceptable Use section of the Terms lists the seven Annex III contexts Wire AI is not to be deployed in, including employment decisions, credit scoring, and the administration of justice. That list lives in one place on purpose, because two copies of a list drift. Read it there. The Annex III obligations themselves apply from 2 December 2027, which is not a reason to wait: if your case sits anywhere near one of those seven, write to us before you switch a surface on.
Transparency: where we stand on Article 50
The transparency duties in Article 50 have applied to new systems since 2 August 2026. What follows is our reading of how they land on Wire AI. It is a reading, not a settled conclusion, and we would rather label it than let it read as one.
Wire AI writes onboarding copy and picks which card a user sees next. It is not a chat interface, and it does not hold a conversation with your user. Our position is that this is an assistive function for standard editing of your own app content, which is the carve-out the article draws itself:
shall not apply to the extent the AI systems perform an assistive function for standard editing or do not substantially alter the input data ... or the semantics thereof
Article 50(2)
Marking at the level of the model sits upstream, with the model provider, not with us. And if you build a chat-like flow of your own on top of Wire AI, disclosure on that flow is yours as the deployer under Article 50(1). Worth knowing before you plan around it: Article 50(1) and 50(3) have bound since 2 August 2026 with no grace period, and the legacy grace that runs to 2 December 2026 is narrower than it usually gets quoted. It covers Article 50(2) only, and only providers of systems that generate synthetic audio, image, video or text.
A German technology lawyer is reviewing this position. We will update this page after that review, including if the answer changes.
The open-source renderer and the commercial kit differ
Wire RN, the renderer, is public and MIT licensed. The commercial kit is not. Article 25(4) says the written-agreement duty does not apply to third parties who make components public under a free and open-source licence, with general-purpose AI models carved back out of that. The two do not carry the same exposure, so we do not describe them as if they did.
Models, data, and where it runs
For the end-user data your app sends us, you are the controller and we are the processor. Concretely, this is what moves.
The answers your users type into a Wire AI onboarding card go to a model provider. Earlier answers are put into the prompt on each adaptive turn, because that is how the next question gets chosen, and there is no version of this product where that is not true. Free text from in-app reviews and questionnaires is different: it is stored, and it stays out of every prompt.
No IP address is stored. There is no column for one anywhere in the schema. No advertising identifier either, and no precise location: country level at most, and only when the incoming request carries a country header. The free-text fields are unbounded, though, so a user can type anything at all into one. Treat them as capable of holding anything, because they are.
The service runs on Fly.io, with its primary region in Frankfurt, Germany.
A data processing agreement and a current list of sub-processors are available on request. The model providers, and every other sub-processor, are named in that list and not on this page, so there is one document we keep current instead of a copy on a web page that quietly goes stale. Retention terms are set out in that agreement too. Ask and you get the current version.
Ask us
For the data processing agreement, the sub-processor list, or anything this page does not answer, write to malik@getwireai.com. If you are weighing a use that sits near one of the Annex III contexts, write before you deploy, not after.
Nothing on this page is legal advice.