AI Transparency Statement

Effective June 5, 2026

Version 1.0 · Last updated June 5, 2026

Controller: Kirill Maximenko (Cyprus self-employed entity, TIN 60056031S)

3 Evagora Pitali, 4040 Germasogeia, Limassol, Cyprus

info@toolum.ai

1. About this Statement

Toolum is built on AI. Every Blueprint you draw passes through one or more large language models, and the quality of what comes back depends on choices we make about which model to use, what context to send it, what to do with the result, and how to be honest with you about all of it.

This AI Transparency Statement explains those choices. It is the technical companion to our Privacy Policy, which covers Personal Data handling end to end. Where the Privacy Policy describes what we process and why, this Statement describes how AI processing works inside Toolum — which providers we route to, what we send them, what they do with it, what the outputs are, and where you sit in control of all of that.

1.1 Why we publish this Statement

We publish this Statement for three reasons.

Transparency. Builders deserve to know how the tool they trust with their ideas actually works. Generic privacy language ("we use AI to provide our service") is true but useless. This document gives you the specific architecture, the specific providers, the specific safeguards.

Regulatory compliance. The EU AI Act (Regulation (EU) 2024/1689) places transparency obligations on providers and deployers of AI systems. The most relevant provision for Toolum is Article 50, which requires (among other things) clear disclosure of AI interaction and machine-readable marking of certain AI-generated content. This Statement is one of the instruments through which we meet those obligations.

Trust. AI tooling is new, the law around it is still settling, and many AI products communicate vaguely or not at all about what happens to your inputs. We would rather over-explain than under-explain.

1.2 Scope

This Statement covers AI processing that happens inside Toolum — the AI features Toolum operates, the AI providers Toolum engages, and the data flows between them. It does not cover:

AI features in third-party tools you might use alongside Toolum (your code editor's AI assistant, your design tool's AI, etc.);
AI processing that the apps you build with Toolum might perform on their own end-users (you, as the Builder, are responsible for disclosing those to your end-users);
AI processing by the AI provider companies themselves outside the scope of the Toolum integration (their general operations, research, and other products).

1.3 How this Statement relates to other Toolum documents

Privacy Policy — the canonical disclosure of Personal Data processing on Toolum. Where this Statement and the Privacy Policy overlap on AI-related processing, the Privacy Policy prevails for binding GDPR interpretation; this Statement provides technical detail.
Subprocessor List — the list of third parties that process Personal Data on Toolum's behalf, including the AI providers covered in Section 3 below.
Terms of Service — defines your rights as a Builder in the outputs Toolum produces for you.
Acceptable Use Policy — describes the uses of Toolum (and of AI outputs) that we don't allow.

1.4 Key terms used in this Statement

AI provider — a third-party company whose foundation models Toolum routes requests to (Anthropic, OpenAI, Google).
Inference — the operation a model performs when it generates a response from a prompt.
Prompt — the natural-language instruction you send to Toolum (or that Toolum constructs on your behalf when, for example, you click a generation action in the visual editor).
Project context — the structured information Toolum assembles around your prompt before sending it to an AI provider: your Blueprint's current state, design system definitions, prior generated content, and relevant references from our curated industry library.
Output — the response Toolum receives back from the AI provider after inference: code, design tokens, copy, images, or other artifacts.
Blueprint — a project, design, generated specification, or code artifact produced through Toolum.
Builder — a registered user of Toolum.

2. AI in Toolum: what it does and what it does not do

This section gives you the high-level map. The detailed technical mechanics start at Section 3.

2.1 What Toolum uses AI for

Toolum uses AI for the following functions:

Blueprint generation — converting your natural-language description of a digital product into a structured project: screens, navigation, components, data models, and behavior.
Code generation — producing exportable source code from your Blueprint, in the target framework you have selected.
Visual asset generation — generating icons, avatars, and other visual elements when you have not supplied them as part of a brand kit. Section 7.4 explains how these visual outputs are marked.
Design system generation — proposing color palettes, typography scales, and component tokens based on your prompt and the references in our curated library.
Content generation — drafting placeholder copy, marketing-style text, and similar editorial content for your Blueprint.
In-editor assistance — answering questions you ask in the chat panel, suggesting refinements to existing components, and helping you debug your Blueprint.

2.2 What Toolum does not use AI for

For clarity, Toolum does not use AI to:

Decide what you can or cannot build. Toolum's role is to help you Build; content moderation of your prompts and outputs happens at the AI provider safety layer, not at a Toolum-operated decision gate.
Build behavioral or psychological profiles of Builders. We do not run AI inference over your usage patterns to model your personality, attribute interests, or predict behavior for marketing or any other purpose.
Make pricing, plan, or commercial decisions on an individual Builder basis. Pricing is uniform per tier and is not adjusted by automated profiling.
Train, fine-tune, or improve any model on your Customer Content. Neither Toolum's own systems nor the third-party models we route to are trained on your prompts, Blueprints, or generated outputs. Section 5 explains the provider-side configuration that makes this true.
Decide who gets banned for abuse. The abuse-prevention system described in Privacy Policy Section 3.4 is a rules-based system over technical signals — it does not use a large language model to make ban decisions.

2.3 The role of human review

Toolum does not insert a human reviewer between you and the AI provider on every request — that would defeat the purpose of an AI-assisted builder. Human review exists at the boundaries:

You are the human reviewer of every output. AI-generated outputs are proposals. You inspect them, modify them, accept them, or reject them. Section 7.3 explains why we strongly recommend you treat every output that way.
AI provider safety teams. Each AI provider operates safety systems that may flag a small fraction of requests for human review on their side, generally for abuse or policy reasons. That review is governed by the provider's own policies (Section 5.4).
Toolum staff. Toolum staff do not routinely read your prompts or outputs. We access Customer Content only in narrow circumstances (debugging at your request, investigating a security incident, responding to a lawful legal process) and only with the safeguards described in Privacy Policy Section 9.

3. The AI providers we route to

Toolum does not train or operate its own foundation models. Every AI-generated output you receive is produced by a third-party inference provider. We currently engage three providers, organized as a primary + fallback chain to maintain Service availability when any single provider has an outage or rate-limits Toolum's traffic.

3.1 Anthropic (primary)

Models used: Claude family (currently Opus, Sonnet, and Haiku tiers, selected per request type — see Section 3.4). API tier: Anthropic Commercial API under Anthropic's Commercial Terms. Location of inference: United States. Transfer mechanism: EU-US Data Privacy Framework certification + Standard Contractual Clauses (see Subprocessor List Section 5.1 and Privacy Policy Section 7). Training opt-out: By default under Anthropic's Commercial Terms, API inputs and outputs are not used to train Anthropic's models. Toolum has not enabled any optional program that would change this default. Provider retention: Anthropic's commercial API retention is short-window (the current published default is up to 30 days for abuse-detection purposes; with a Zero Data Retention agreement available for eligible use cases). Toolum monitors provider documentation for retention changes and will revise this Statement when material changes occur.

Anthropic is our primary provider for most Builder interactions because of the quality of its frontier models on the reasoning and code-generation tasks Toolum prioritizes, and because of the strength of its commercial privacy posture.

3.2 OpenAI (fallback)

Models used: GPT family (selected per task — code generation, content drafting, and similar). API tier: OpenAI API under OpenAI's API Terms. Location of inference: United States. Transfer mechanism: EU-US Data Privacy Framework certification + Standard Contractual Clauses. Training opt-out: By default under OpenAI's API Terms, API inputs and outputs are not used to train OpenAI's models. Toolum has not enabled any optional program that would change this default. Provider retention: OpenAI's API retention has been progressively shortened — current published default is short-window for abuse detection. Toolum monitors provider documentation and will revise this Statement when material changes occur.

OpenAI serves as the first fallback when Anthropic is unavailable, rate-limited, or returns an error for a specific request.

3.3 Google (fallback)

Models used: Gemini family. API tier: Google Cloud Gemini API under Google Cloud Terms. Location of inference: United States. Transfer mechanism: EU-US Data Privacy Framework certification + Standard Contractual Clauses (Google Cloud DPA). Training opt-out: By default under the Google Cloud Gemini API paid tier terms, API inputs and outputs are not used to train Google's models. Toolum uses the paid tier exclusively (not the consumer-grade free Gemini service). Provider retention: Google Cloud's published API retention is short-window for abuse detection. Toolum monitors provider documentation and will revise this Statement when material changes occur.

Google serves as the second fallback, used when both Anthropic and OpenAI are unavailable for a specific request.

3.4 How routing decisions are made

For each request Toolum sends to AI providers, the routing decision is made by Toolum's backend based on:

The type of task. Code generation, design-system reasoning, and visual asset generation have different model strengths; Toolum selects the model class accordingly (for example, larger reasoning models for complex Blueprint generation, smaller faster models for quick edits).
The active tier. Some model classes carry higher per-request cost; Toolum's tier system (see Privacy Policy Section 2.1 and Toolum's pricing page) governs which tiers can access which model classes.
Provider availability. When the primary provider returns an error, is rate-limited, or exceeds a latency threshold, Toolum's fallback chain (Anthropic → OpenAI → Google) routes the request to the next available provider transparently.
Cost-gating safeguards. Toolum enforces per-tier monthly spend ceilings to protect both Builders from accidental over-consumption and Toolum from runaway costs. When a Builder approaches their tier ceiling, Toolum notifies them and offers an upgrade path; AI requests beyond the ceiling are paused until the next billing cycle or an upgrade.

Routing decisions are made in milliseconds inside Toolum's backend and are not the kind of "automated decision-making" that produces legal effects under GDPR Article 22. (The abuse-prevention system, which can suspend an account, is subject to Article 22 — see Privacy Policy Section 13.)

3.5 Why we use three providers instead of one

A single-provider AI architecture has two failure modes that we consider unacceptable for Toolum:

Provider outage means Toolum outage. When an AI provider has a major outage (which happens to all of them periodically), every product that depends on that single provider goes down. The fallback chain means Toolum continues to serve Builders even when one provider is degraded.
Provider policy or pricing changes leave you stranded. If a single provider raises prices, deprecates a model you depended on, or changes its acceptable-use policies in ways that affect your work, you have no recourse. Toolum's multi-provider architecture lets us adapt without disrupting your Blueprints.

The trade-off is that your prompts may be processed by different providers across different sessions or even different parts of the same session. We accept that trade-off because the alternative — periodic Service outages — would be worse for everyone.

4. What you send to AI

Every time Toolum produces an AI-generated output for you, a request is sent to the active provider. This section describes exactly what is in that request.

4.1 Your prompts

The most direct part of any AI request is the prompt you sent — the natural-language instruction you typed into Toolum's chat panel, the description you wrote when starting a new Blueprint, or the refinement note you added to an existing component.

Your prompt travels to the AI provider verbatim. Toolum does not rewrite, paraphrase, or substantively transform your wording before sending it, because doing so would degrade the quality of what the provider returns.

4.2 Project context Toolum constructs around your prompt

A prompt on its own is rarely enough for an AI provider to produce a useful Blueprint output. Toolum's backend constructs a structured project context that accompanies the prompt and gives the provider the information it needs to respond well. That context includes:

The current state of your Blueprint. Screen structures, component definitions, navigation graph, data models you have already set up.
Design system tokens. Colors, typography, spacing scales, and component styles that you have either supplied (via a brand kit) or that Toolum has previously generated for this Blueprint.
Conversation history within the current Blueprint. Recent exchanges so the AI can maintain continuity of intent across multiple prompts.
Relevant references from the curated industry library. A small selection of references from the library described in Section 6 — chosen by Toolum based on the Blueprint's industry category.
System instructions. A Toolum-authored instruction layer that defines the AI's role for this request (for example, "you are generating a React component for a Blueprint in the e-commerce category, follow these constraints…").
Operational metadata. Model identifier, generation parameters (temperature, max tokens), and identifiers Toolum uses internally to correlate requests with sessions.

The project context is constructed on each request. Toolum does not maintain a long-term context store that the AI provider can independently access; the provider receives only what is in this one request.

4.3 What we do not send

To make the boundaries clear:

Your email address, account identifier, or any account-level identifier is not transmitted in the request. The provider has no way to associate a request with you as a person unless your prompt itself contains such information.
Your password, payment information, or any authentication credential is never transmitted.
The Customer Content of other Builders is never transmitted in your request, regardless of any context-sharing features that might be developed in the future.
PostHog usage telemetry, billing records, or internal Toolum operational data about you is not transmitted.

4.4 What happens if your prompt itself contains Personal Data

You may include Personal Data in your prompts — for example, sample user names while designing a registration flow, or a real customer description while drafting an email template. When you do, that Personal Data travels with the prompt to the AI provider.

Toolum does not scrub Personal Data from prompts before sending them, because we cannot reliably distinguish "Personal Data that you wanted to use as an example" from "Personal Data that should not have been included." That judgment is yours.

A practical recommendation: if you would not paste a piece of information into a third-party chat assistant, do not paste it into a Toolum prompt either. Use placeholders ("user@example.com" instead of a real email) for design and prototyping work.

The legal framework that applies when your prompts contain Personal Data of others is described in our Data Processing Addendum.

5. What AI providers do with your data

This section describes what the AI providers we route to do (and do not do) with the data Toolum sends them.

5.1 Default commercial API behavior

Toolum accesses every AI provider through their commercial API tier, not their consumer products. This distinction matters because consumer products (the public chat interfaces operated by Anthropic, OpenAI, and Google) and commercial APIs operate under different privacy defaults — and the commercial API defaults are substantially more protective.

Under the commercial API terms of all three providers:

Inputs and outputs are not used to train, fine-tune, or improve the provider's foundation models by default. This is a contractual commitment, not a configuration flag we toggled.
Inputs and outputs are retained only for short operational windows (typically up to 30 days) for abuse detection and incident response, after which they are deleted automatically. Some providers have shortened these windows further in recent years; check the current published retention policy of each provider for the most recent number.
Inputs and outputs are not shared with other customers of the same provider, and are not used to inform responses to other customers.
Provider personnel access inputs and outputs only under narrow safety-team circumstances (Section 5.4 below).

5.2 No training on Customer Content

This deserves its own subsection because it is the question Builders ask most often.

Toolum does not train any AI model on your Customer Content. This is true at every layer:

At the Toolum layer. Toolum does not operate a foundation model, so there is nothing for us to train. Toolum may in the future develop adapter layers, fine-tunes, or specialized retrieval models on top of provider foundation models — if and when that happens, this Statement will be revised to describe what those systems are trained on, and you will be notified of the material change per Section 11.
At the provider layer. As described in Section 5.1, all three providers we route to operate their commercial APIs with training-on-inputs disabled by default. Toolum has not enrolled in any optional provider program that would change this default.
At any future Toolum-internal model layer. If Toolum ever builds an internal model — for example, a small fine-tuned model for cost optimization on routine code edits — its training data will be sourced from synthetic data, public datasets with appropriate licensing, or Customer Content that you have explicitly opted in to contribute. Default behavior will remain no-training-on-Customer-Content.

5.3 Provider retention windows

Each AI provider applies its own retention window to the data Toolum sends. Current published defaults (as of the Last Updated date at the top of this Statement) are short — generally up to 30 days for commercial API customers, with some providers having shortened windows further for specific use cases.

What this means practically:

A prompt you sent yesterday is held by the provider for a short window for abuse detection, and is then automatically purged.
An output the provider generated for you yesterday follows the same retention as the prompt.
You cannot retrieve a prompt or output from the provider after their retention window has elapsed — the data simply no longer exists at the provider.
Toolum's own retention of your prompts and Blueprints is separate and is governed by our Privacy Policy Section 8.

Where a provider offers Zero Data Retention (ZDR) as an option for commercial API customers, Toolum will evaluate enabling it when the resulting trade-offs (cost, latency, feature availability) are acceptable. ZDR availability and Toolum's enrollment status will be disclosed here as it changes.

5.4 Human review at provider side

Provider safety teams may review a small fraction of API inputs and outputs flagged by automated safety systems. Each provider has its own safety policies that determine when human review occurs; in general, human review is triggered by patterns the provider's safety classifiers associate with abuse, policy violations, or potential harm.

When a provider safety review occurs:

It happens at the provider, not at Toolum;
It is governed by the provider's privacy policy, not by Toolum's policies;
Toolum is not informed of the review unless the provider escalates an issue to Toolum's account;
The review is not used to train the provider's models.

Builders who want more detail on provider-side safety review should consult the privacy policies of Anthropic, OpenAI, and Google directly (linked from Subprocessor List Section 5.1).

5.5 Where the trust chain sits

It is reasonable for you to ask: if Toolum sends my prompt to a US-based AI provider, on what basis should I trust that the provider actually adheres to its stated commercial API terms?

The answer is layered:

Contractual commitments. Toolum has executed Data Processing Agreements with each AI provider that contractually bind them to the protections described in Section 5.1.
Independent certifications. Each provider holds public attestations (SOC 2, ISO 27001, EU-US Data Privacy Framework certification) that demonstrate independent verification of their data-handling practices.
Regulatory enforcement. Each provider is subject to enforcement under the GDPR, the EU AI Act, the FTC Act, and other applicable laws. Violation of stated terms exposes the provider to substantial penalties.
Reputational stakes. Each provider's commercial business depends on enterprise customers trusting that API data is handled per stated terms. A provider that violated those terms would face customer loss far exceeding any short-term gain.

The trust chain is not perfect — no provider relationship is — but it is the same trust chain that every commercial AI deployment in the EU currently relies on, and Toolum has chosen providers and contractual structures with that scrutiny in mind.

6. The curated industry reference library

A central piece of Toolum's value is the curated industry reference library — a structured collection of design patterns, component patterns, and UI conventions that Toolum's engineers have assembled by hand across many industries. This section explains what the library is, what it is not, and how it gets used.

6.1 What the library is

The library is a structured lookup table maintained by Toolum's engineers. For each industry category Toolum supports (currently spanning many industries, with continuous expansion), the library contains:

Common screen patterns typical for products in that industry (for example, "onboarding flow with progressive disclosure" for productivity apps, "menu + cart + checkout" for food-service apps);
Component conventions that Builders in that industry expect (form patterns, navigation patterns, list-and-detail structures);
Design system defaults that match industry visual norms (typography weight, spacing density, color temperature);
Domain vocabulary appropriate to the industry (so Toolum doesn't propose "checkout" terminology in a Blueprint for a wellness app where "complete session" is the natural term).

The library is curated, not crawled. Each entry has been reviewed and structured by a Toolum engineer rather than scraped from the public web.

6.2 What the library is not

Three things the library deliberately is not:

Not a retrieval-augmented generation (RAG) corpus. Toolum does not embed Builder prompts as vectors, search a vector database for nearest neighbors, and inject retrieved chunks into the AI request. RAG is a powerful pattern; we have chosen a different one.
Not training data for any model. No entry in the library is used to train, fine-tune, or otherwise adjust any AI model. The library is a runtime lookup, not a training corpus.
Not a place where Customer Content lives. Your Blueprints, prompts, generated outputs, and project context are never added to the library. The library is read-only from the perspective of any single Builder request.

6.3 Where the references come from

The references in the library are derived from publicly observable industry patterns — the kinds of UI patterns you would identify yourself if you looked at twenty leading apps in a given category and noted what they have in common. Toolum's engineers have done that observation work, structured the observations, and committed the result to the library so that every Builder benefits from it instantly.

The library does not contain copyrighted assets, proprietary code, or trade secrets of any specific company. It contains the abstracted patterns — the structural and conventional knowledge — that exists in the public design vocabulary of an industry.

6.4 How the library affects your Blueprint

When you start a Blueprint and indicate (or Toolum infers) the industry category, a small selection of references from the library is added to the project context that Toolum constructs around your prompt (Section 4.2). The references give the AI provider grounding in the conventions of your industry so that the first proposal is closer to what you actually want.

You can override library defaults at any point — by describing a non-standard pattern in your prompt, by editing the design system tokens directly, or by importing your own brand kit. The library is a starting point, not a constraint.

7. AI-generated outputs (the Blueprints)

This is the section about what comes out of Toolum: code, design assets, copy, and the rights and responsibilities that attach to each.

7.1 Ownership and use rights

You own the AI-generated outputs Toolum produces for you, subject to the limitations described in our Terms of Service. Specifically:

The code Toolum exports to you is yours to use, modify, deploy, ship, sublicense, and sell in the products you build, without paying Toolum royalties on those products.
The design system, visual assets, and content Toolum generates for you are yours under the same terms.
Toolum does not retain a claim on your Blueprints or their commercial use.

"Ownership is the product" is one of Toolum's brand commitments and it shows up in the legal terms. Where the Terms of Service and this Statement diverge on a specific point of output rights, the Terms of Service prevails.

7.2 No warranty of originality

AI-generated content can resemble existing works. This is a structural property of how large language models work — they have been trained on vast corpora, and their outputs reflect patterns learned from that training. We make no warranty that any AI-generated output is original, novel, or free of similarity to existing works. In particular:

Generated code may resemble code patterns that exist in public repositories or common tutorials. The patterns themselves are generally not protectable, but specific implementations may be.
Generated design assets may resemble visual styles common to a given industry or aesthetic category.
Generated text may include phrasings common to the topic being written about.

If you intend to publish, ship, or commercially exploit an AI-generated output in a way that requires originality (for example, as part of a trademark application or a copyrighted brand asset), you should conduct an independent review of the specific output before doing so. Toolum does not perform that review on your behalf.

7.3 Human review recommendation

We strongly recommend that you review every meaningful AI-generated output before relying on it. AI models — including the frontier models Toolum routes to — produce content that is plausible-sounding more reliably than it produces content that is correct. Specific risks:

Code may contain logic errors, security vulnerabilities, or outdated patterns. Run it, test it, audit it before shipping.
Generated text may contain factual errors or hallucinated references. Verify any claim, statistic, or citation before publishing.
Generated assets may unintentionally resemble protected works. Check before commercial use.
Generated content may carry biases present in the underlying model's training data. Review with the audience and use case in mind.

Toolum gives you the tools to inspect, edit, and reject outputs at every step. Use them.

7.4 Marking and disclosure of AI-generated outputs

Toolum approaches the EU AI Act's transparency requirements (Regulation (EU) 2024/1689, Article 50) as follows.

Exported source code. When you export code from Toolum, the code is delivered with an optional comment header at the top of each commentable source file (for example JavaScript and TypeScript files; some non-code files such as JSON or image assets carry no comment header):

// Generated by Toolum — https://toolum.ai/legal/ai-transparency
// Project: <your project name> · YYYY-MM-DD

This header exists for transparency and attribution. It is not a watermark and contains no hidden signals: it is plain text, fully visible, and you may delete it from any file without consequence. The European Commission's Draft Guidelines on Article 50 (paragraph 64) exempt source code outputs from the machine-readable marking requirement of Article 50(2); we provide the header anyway because we believe AI provenance disclosure is good practice and because some Builders find the attribution useful.

Code export itself is available on the Builder tier starting at €100/month and above. Builders on the Free tier and the Starter €25 tier do not have code export and therefore do not encounter this header.

README provenance line. Blueprints exported with code include a short provenance line in the generated README.md — it states that the project was generated by Toolum and links to this AI Transparency Statement. This line is plain, visible Markdown; it carries no hidden signals, and you may remove it manually from the exported README.md without affecting your project or your Toolum subscription.

Provenance of AI-generated image assets. Toolum currently does not generate image assets through AI inference. Icons, splash screens, and other visual elements in your projects are composed deterministically from a curated icon library, not produced by an AI image model.

When Toolum adds AI image generation as a feature (planned for a future phase of our roadmap), generated images will include provenance metadata using established industry standards (C2PA / IPTC fields where the file format supports them) so that detection tools and downstream platforms can recognize the AI origin. We will update this Statement when AI image generation activates, and notify you per Section 11.

Generated standalone text (such as marketing copy, blog-style content, or other documentation that is not source code) is delivered with a clearly visible header identifying the content as AI-generated. As with the code comment header, this notice is removable; we provide it as a transparency default.

AI interaction disclosure. When you are interacting with Toolum's AI assistants directly — in the chat panel, in an in-editor suggestion, in a generation action — the Toolum interface clearly identifies the assistant as AI, consistent with EU AI Act Article 50(1). You will always know you are talking to a model, not to a human.

No steganographic or non-removable markings. Toolum does not embed hidden watermarks in code, does not apply non-removable signals to text outputs, and does not use machine-detectable patterns that survive routine code transformations. Marking on Toolum outputs is transparent, visible, and explicitly designed to be removable by the Builder who owns the output.

8. Limitations and risks

AI systems are powerful and they are also fallible in specific ways that you should understand before relying on their outputs.

8.1 Hallucinations and factual errors

Large language models can produce content that is fluent, confident, and wrong. The technical term is hallucination, and it affects every frontier model in current production.

Practical examples in the Toolum context:

A generated code snippet that references a library function which does not exist in the library version you are using;
A generated documentation paragraph that cites a statistic without a real source;
A generated component that uses a CSS property in a way the browser does not actually support.

We strongly recommend you verify any factual claim, library reference, or specific technical detail in an AI-generated output before relying on it.

8.2 Bias

AI models reflect patterns in their training data. Where the training data is uneven across demographics, geographies, languages, or cultural contexts, the model's outputs will be uneven too.

In Toolum's context, this can show up as:

Generated copy that defaults to American English idioms when you intended international tone;
Generated user-flow assumptions that fit Western consumer apps better than other markets;
Generated visual references that under-represent certain demographics.

We mitigate where we can — Toolum's curated reference library (Section 6) is one such mitigation, designed to ground outputs in specific industry conventions rather than the model's defaults — but you should review outputs with your audience in mind.

8.3 Not legal, medical, financial, or professional advice

Toolum is a digital product builder. It is not a substitute for licensed legal counsel, medical professionals, financial advisors, or any other regulated profession.

In particular:

Do not use Toolum-generated text as legal terms, contracts, or compliance documentation without review by a qualified attorney.
Do not use Toolum-generated content for medical diagnosis, treatment recommendations, or health-related decisions without review by a qualified medical professional.
Do not use Toolum-generated content for financial advice, investment recommendations, or tax positions without review by a qualified financial professional.

If you build a Blueprint for a regulated domain (health, finance, legal, education), you are responsible for ensuring that the deployed product meets all applicable regulatory requirements for that domain. Toolum does not warrant compliance with domain-specific regulations.

8.4 Code quality caveats

Generated code is starting-point code. It compiles, it runs, and in many cases it does exactly what you wanted. It is not, by default:

Security-audited. Generated code may contain vulnerabilities (injection risks, authentication gaps, exposed secrets). Audit before deploying to production.
Performance-optimized. Generated code may be readable but inefficient. Profile before scaling.
Accessibility-complete. Generated UI may not meet WCAG criteria out of the box. Review accessibility before shipping to users.
Internationalization-ready. Generated code may hard-code English strings or US-formatted dates. Internationalize before serving non-English markets.

These caveats are not unique to Toolum — they apply to AI-generated code from every current generation tool. We mention them explicitly because we would rather you ship a reviewed Blueprint than a brittle one.

8.5 Provider availability

Toolum depends on third-party AI providers (Section 3). When those providers have outages, degraded performance, or rate-limit Toolum's traffic, Toolum's AI features may be affected. Our fallback chain (Section 3.4) mitigates single-provider failures, but a sufficiently widespread outage across multiple providers can still disrupt the Service.

Builders with time-sensitive Blueprint deadlines should plan for occasional provider-side incidents, just as they would plan for any third-party dependency.

9. Your controls

This section describes the controls you have over AI processing on Toolum.

9.1 Choosing what to send

The most powerful control is at the source: what you put into a prompt. As described in Section 4.4, Toolum does not scrub Personal Data or sensitive information from prompts. You decide what travels with each request.

Practical controls:

Use placeholder data instead of real Personal Data when prototyping;
Compose prompts narrowly — provide what the AI needs to do this specific task, not your full context;
For sensitive Blueprints, consider whether the work belongs in a no-code AI tool at all (some categories of work require air-gapped tooling or on-premise inference, which Toolum does not currently provide).

9.2 Deleting your Blueprints and prompts

You can delete a specific Blueprint, a specific prompt within a Blueprint, or your entire account at any time through the Toolum interface.

When you delete:

The Blueprint, prompt, or account is removed from Toolum's active systems within thirty (30) days, per Privacy Policy Section 8;
Provider-side retention of the prompt at the AI provider continues for the provider's own retention window (typically up to 30 days) and is then purged automatically by the provider;
Once both windows have elapsed, the data no longer exists at Toolum or at the provider.

You do not have a separate mechanism to instruct the AI provider to delete a specific prompt before its retention window elapses — provider commercial APIs do not generally expose that as a per-record operation. The retention window is the deletion mechanism.

9.3 Exercising data subject rights

The full set of data subject rights described in Privacy Policy Section 10 — access, rectification, erasure, restriction, portability, objection, withdrawal of consent, the right to lodge a complaint, and the Article 22 human review right for automated decisions — applies to AI processing as well as to all other Personal Data processing on Toolum.

To exercise any right, contact info@toolum.ai.

9.4 Refunds where AI processing affects your purchase

If an AI feature did not work as described in this Statement, in our Terms of Service, or in our published documentation, our Refund Policy applies. The pro-rata refund framework for AI Credit Bundles ensures you do not pay for credits unused because of AI feature defects.

10. AI interaction disclosure

EU AI Act Article 50(1) requires providers of AI systems intended to interact directly with natural persons to ensure that the persons concerned are informed that they are interacting with an AI system, unless that fact is obvious from context.

This section describes how Toolum meets that obligation.

10.1 You are talking to an AI

Wherever you interact with an AI assistant on Toolum — the chat panel, the in-editor suggestion overlay, the generation actions on components — the interface identifies the assistant as AI. The identification is in the UI itself — the assistant is labeled as AI and noted as powered by Claude, with a visual marker distinguishing it from human Toolum staff — and is reiterated in the chat panel introduction text.

You will never be in doubt about whether you are talking to a human or to a model.

10.2 Human support is distinct from AI assistance

Toolum operates a human support channel through info@toolum.ai. Messages to that address are read and responded to by a human (currently the founder, with that designation made explicit). The AI assistants inside the Toolum product do not represent themselves as human staff and do not pretend to escalate to human support — when you need human support, the explicit channel is the email address.

10.3 In-product AI labeling

Beyond the chat panel, Toolum uses consistent visual conventions to mark features that depend on AI inference:

AI-driven generation actions are labeled with the AI assistant's identity;
AI-generated content within the editor (proposed text, proposed components) is visually distinguished from content you authored directly;
Real-time status indicators show when an AI request is in flight.

These conventions exist so that you always know which parts of your Blueprint are AI proposals (which deserve review) and which parts are your direct work.

11. Changes to this Statement

We may update this AI Transparency Statement when our AI architecture changes, when we add or replace AI providers, when applicable law changes (the EU AI Act is itself still being implemented through guidelines and codes of practice), or when our practices evolve.

11.1 How we publish changes

The same versioning convention as our Privacy Policy applies:

The "Last Updated" date at the top of this document is revised on every change;
The "Effective Date" is revised when material changes take effect;
A change summary is published alongside the document for material changes;
Historic versions are available at their dated URLs under /legal/ai-transparency/<date> and preserved in our public repository.

11.2 When we notify you of changes

For material changes — for example, adding a new AI provider, changing the retention or training posture of an existing provider, introducing AI features that process new categories of data, or changes to the marking conventions described in Section 7.4 — we provide notice at least fourteen (14) days before the change takes effect, through the same channels as for Privacy Policy updates:

An email to the address on your Toolum account;
An in-product notification when you next sign in;
A prominent notice on https://toolum.ai.

For non-material changes (typo corrections, link updates, clarifying rewordings that do not change substance), we revise the document and update the "Last Updated" date without separate notice.

11.3 Your options when this Statement changes

If a material change to this Statement is unacceptable to you, you may stop using the Service before the change takes effect. Per our Refund Policy, unused AI Credit Bundles purchased before the change are refundable on a pro-rata basis.

12. Contact

For questions about this AI Transparency Statement, about Toolum's AI architecture, or to provide feedback on the marking conventions described in Section 7.4:

Controller

Kirill Maximenko (Cyprus self-employed entity)
Tax Identification Number: 60056031S
Address: 3 Evagora Pitali, 4040 Germasogeia, Limassol, Cyprus
Email: info@toolum.ai

Cyprus supervisory authority

If you have a complaint about Toolum's AI processing that you would prefer to raise with a supervisory authority, the lead authority for Toolum is the Commissioner for Personal Data Protection of the Republic of Cyprus:

Office of the Commissioner for Personal Data Protection
Office address: Kypranoros 15, 1061 Nicosia, Cyprus
Postal address: P.O. Box 23378, 1682 Nicosia, Cyprus
Telephone: +357 22 818456
Email: commissioner@dataprotection.gov.cy
Website: https://www.dataprotection.gov.cy