AI inside Redmine, running on your own provider account, with the model you choose.
Summarize a forty-comment issue in seconds. Draft the reply. Turn a messy description into a well-formed ticket. Ask questions across a project and get answers with citations, so an answer can be checked rather than taken on faith.
The part that matters most is not what Zaira does. It is whose account it does it in. You connect your own AI provider, and your content goes from your workspace to that provider under terms you already accepted. RedminePRO is not in the middle of it, and we never receive the content.
That is a different shape of answer from the usual one. Most AI features in this category route your data through the vendor, who then promises not to keep it. The promise may well be kept. It is still a promise about someone else's systems, and verifying it is not something you can do. Here there is nothing to verify, because there is no third party in the path.
Two consequences follow. You choose the model rather than living with ours, and you can change your mind later without leaving the product. And because we are not paying for the inference, Zaira is on every plan from Startup upwards with no usage cap from us.
OpenAI, Anthropic and Google Gemini each take an API key. AWS Bedrock takes an access key, a secret and a region. The fifth slot covers anything OpenAI-compatible, including Azure OpenAI, which is how most of the remaining providers are reached.
Model names are plain strings you set rather than a fixed list we maintain, so a model released next month is available to you the day it exists rather than the day we get round to adding it.
The question is usually some form of does our data leave our cloud. On Bedrock the answer is no: inference runs inside your own AWS account and in the region you choose.
RedminePRO already runs entirely on AWS. A customer using their own Bedrock account can therefore keep the whole path inside AWS, under their own account, in a region they picked. That is a materially easier conversation than explaining which third party receives your ticket text and what their retention policy says.
Summarize sits on the issue page and returns what happened, the decisions, the open points and suggested next steps. Forty comments of back and forth become something you can read before a meeting.
Draft sits in the note editor. Give it an instruction and a tone and it writes into the editor. It never posts.
Create turns pasted text, an email or a meeting note, into editable draft issues.
Ask is a project tab that answers from that project's issues and wiki, with numbered citations pointing at the sources it used. A cited answer can be checked. An uncited one has to be believed, which is not a useful property in a work tool.
Everything Zaira produces is a draft for a human to review. The feature never creates, edits or posts anything on its own. That is a deliberate boundary rather than a current limitation.
What is sent is the issue text relevant to the action: the subject, the description and the comments that user can already see. For Ask, the retrieved passages, scoped the same way. Zaira never shows a user something their permissions would otherwise hide.
What is never sent: attachments, in any circumstance. Private notes, unless an administrator enables them and the requesting user may read them anyway. Custom fields, unless an administrator allowlists them by name. And anything at all from a project that has not switched the feature on, since it is off by default per project.
Before anything leaves, email addresses, phone numbers and any patterns an administrator configures are replaced with placeholders. The mapping back to the real values exists only for the duration of that request and is never stored.
One audit row per call. It records who, when, which feature, which project or issue, the provider, the model, token counts, duration, how many redactions were applied, and whether the call succeeded.
The content of the prompt and the response is never stored, and the reason is worth stating precisely: the audit table has no column that could hold it. That is a structural fact about the schema rather than a policy we are asking you to trust. A policy can change with a deployment. A column that does not exist cannot quietly start being filled.
Issue summaries are cached so that reopening an unchanged issue costs nothing. That cache holds output the user has already seen, not provider payload.
Each user agrees once before their first use. The consent screen names the real provider rather than hiding it behind the persona, and any user can withdraw from My account at any time, which switches Zaira off for them.
Administrators can set monthly quotas for the workspace as a whole and per user, in requests or tokens, with blank meaning unlimited. Only successful calls count, so a provider outage never eats someone's allowance. Usage by user, feature and provider is visible in administration.
Zaira is on every plan, including Startup, at no extra cost from us. You pay your own provider for the inference you use. Administrators are not exempt from consent, and the feature is enabled per project rather than sitewide.
The data flow is described in full in our privacy policy, and the security page covers where RedminePRO itself runs. Compare the plans, or see the rest of what RedminePRO adds to Redmine.
14-day trial on any plan. Zaira is included from Startup upwards.