AI Features Terms
IN FORCE. See 00-README. Governs CIQRA's AI-assisted features. Complements the ToS, Privacy Policy §4, DPA §13, and Acceptable Use Policy.
Legal basis. Every provision below rests on one of three things: a measured fact about the platform (cited to file and line), a rule of law (cited to the instrument and article in the Legal Basis Register), or a commercial choice CIQRA has made where the law leaves it open. Prepared and adopted by CIQRA OÜ.
Provider: CIQRA OÜ, Tallinn, Estonia · In force from: 2026-08-09 · Version: 1.0 · Adopted by: CIQRA OÜ
1. What the AI features are
CIQRA offers optional AI-assisted features — AI product-description/SEO generation, semantic search and recommendations, image generation/editing, and an AI assistant/copilot — delivered via third-party AI providers. Availability is plan-gated and features may change or be withdrawn (beta terms may apply).
Providers actually wired into the platform (re-measured 2026-08-28: ciqra-saas/src/modules/Ciqra.Modules.Ai/DependencyInjection/AiServiceCollectionExtensions.cs:134-149):
| Provider | Used for | Registration |
|---|---|---|
| Microsoft — Azure OpenAI | Text generation — the resolved text provider, see §1.1 | :135 IAiChatClientFactory, AzureOpenAiChatClientFactory |
| OpenAI | Text generation; embeddings | :134 OpenAiChatClientFactory, :137 OpenAiEmbeddingProvider |
| Voyage AI | Embeddings — default embedding provider | :136 VoyageEmbeddingProvider (https://api.voyageai.com/v1/embeddings, VoyageEmbeddingProvider.cs:25) |
| fal.ai | Image generation / editing | :143 FalImageProvider, :146 FalGenerativeImageProvider, :149 FalSceneImageProvider |
🔴 Anthropic (Claude) was removed from this table on 2026-08-27 because the integration left the code, not because a contract was cancelled. AnthropicChatClientFactory.cs, its service registration and the Anthropic SDK package were deleted in one commit (requirement AI-02, partial — see §1.1). There is no longer any code path that can route an AI call to Anthropic. This does not erase the past: ai_usage_records rows written before that date still carry the provider string anthropic, and CIQRA's retention and data-subject obligations for the inputs those calls transferred are unaffected by the code deletion. Anthropic is therefore carried as a former recipient in §2.4 and in the Subprocessor List §4 rather than being deleted from the record.
🔴 The line numbers in the table above moved, and nothing noticed for seventeen days. The 2026-08-09 version of this table cited :92–:102. Those registrations moved to :124–:135 (the shift was the ValidateOnStart block and the Azure OpenAI client added between them), and moved again to :123–:138 on 2026-08-27 when the Anthropic registration was deleted from the middle of the block. The second move was caught on the commit that caused it, by the mechanism this paragraph describes — which is the whole difference between the two events. A citation to :92 landed on services.TryAddSingleton(TimeProvider.System); when that was written — a line about clocks, offered as the evidence that Anthropic is the text default. It lands on AiDbContext.UseVectors(npgsql); today (2026-08-28): the illustration itself drifted, which is the argument rather than a flaw in it. What :92 names has changed twice and has never once been a provider registration. A positional citation goes stale silently: nothing errors, nothing turns red, the sentence simply stops being backed. That is why legalgate.py's CITATIONS check now dereferences every file:line in this document set and fails when the cited line does not exist. It is the mechanism that stops this recurring; the table above is the manual correction for the one occurrence.
🟢 They moved a third time on 2026-08-28, and this time the mechanism stopped a deploy rather than a reader. Two unrelated changes to the same file — the deletion of the Anthropic factory (plan 06-06) and the addition of an IRequestContext registration above the block (AI-06) — pushed every registration down eleven lines, to :134–:149. Nobody re-read this table. AIWIRING did: it dereferenced the citations, found :123 landing on a comment, and refused the release preflight. The seventeen-day silence of 2026-08-09 and the same-hour red of 2026-08-28 are the same drift with and without a check. The table above and §1.1 below are the manual correction for this occurrence; the durable half is AIWIRING's symbol arm, added in the same commit (see the ⚠️ note in Subprocessor List §4 for what that arm caught that the token test could not).
🔴 Correction of an earlier internal version statement — no self-hosted AI gateway exists. An earlier internal version of this document and of the Subprocessor List stated that AI traffic is "accessed through a self-hosted AI gateway on CIQRA's Azure (Germany) infrastructure". That is not what the code does (measured 2026-08-09, re-confirmed 2026-08-26, re-pointed 2026-08-27 and 2026-08-28: AzureOpenAiChatClientFactory.cs:85-96 constructs the provider SDK over a pooled HttpClient (:90) and calls the provider endpoint directly (:96); AiServiceCollectionExtensions.cs:106 options.VoyageBaseUrl and AiServiceCollectionExtensions.cs:116 options.FalBaseUrl set BaseAddress to the Voyage and fal.ai vendor endpoints). ⚠️ The 2026-08-09/08-26 versions of this sentence evidenced the same fact from the Anthropic chat-client factory, lines 30 to 38. That file no longer exists (§1), so the citation was moved to the factory that now carries the behaviour rather than left pointing at nothing — the finding is unchanged, only the file that evidences it. (The superseded reference is written as prose, not in the backticked file:line form: quoting a broken citation in citation format asserts it, and legalgate.py's CITATIONS check correctly failed the first draft of this very sentence for doing so.) AI requests leave CIQRA's Azure Germany environment and go directly to the provider. This document and the Subprocessor List have been corrected. That statement remains true of the Azure OpenAI path as well: there is still no gateway — the request goes straight to the Azure OpenAI account's own endpoint. What changed is the destination, not the shape. The consequences are worked out in §1.1 and §2.4.
1.1 Azure OpenAI: wired 2026-08-26, and what that does and does not change
🔴 This section replaces the paragraph that said the migration had not been made. That paragraph committed this document to keep naming Anthropic, OpenAI, Voyage and fal.ai as the live providers "until the migration ships", on the principle that restating an intended end-state as a current state would misdescribe where personal data actually goes. That principle is kept — it is why this section is written as carefully as it is, and it now cuts the other way.
What shipped. Azure OpenAI is engaged. There is a client factory, a named HTTP client and a service registration (measured 2026-08-26, re-pointed 2026-08-28: Providers/AzureOpenAiChatClientFactory.cs; AiServiceCollectionExtensions.cs:124 AzureOpenAiTransportHandler and AiServiceCollectionExtensions.cs:125 AzureOpenAiChatClientFactory register the transport handler and the named client, :135 IAiChatClientFactory, AzureOpenAiChatClientFactory registers the factory). The account is ciqra-openai-prod, germanywestcentral; the endpoint and key are held in Azure Key Vault. Landed by plans 06-01/06-03 of the phase tracked as requirements AI-01/AI-03.
🔴 AI-02 has landed for ONE provider of three, and this document states the partial state rather than rounding it in either direction. As of 2026-08-27 Anthropic is removed — the factory class, its service registration and the SDK package were deleted together, and no code path can route to it (§1). OpenAI-direct and Voyage are NOT removed: they remain registered and callable at AiServiceCollectionExtensions.cs:134 OpenAiChatClientFactory, :136 VoyageEmbeddingProvider and :137 OpenAiEmbeddingProvider. So the table in §1 lists four live providers, not one and not five, and §2.4 and the Subprocessor List §4 keep every row that describes a live recipient.
The rule this document has followed since 2026-08-09 is unchanged and now cuts both ways: a subprocessor list that dropped a provider the code can still call would misdescribe the processing chain — which is why OpenAI-direct and Voyage keep their rows — and a list that kept naming a provider the code can no longer call would misdescribe it in the other direction, which is why Anthropic's row moved to former recipient rather than staying live. Neither is a contract statement: §2.3's open item about executed provider terms is unaffected by either change.
What is added, not swapped. Until AI-02 lands, Azure OpenAI is an additional recipient rather than a replacement for any of the others.
2. How your data is handled (data minimisation + no-training)
2.1 Minimisation. CIQRA sends AI providers only the input needed for the requested feature, and avoids sending personal data / PII except where strictly necessary and disclosed.
2.2 No training on your data; zero/limited retention. CIQRA uses AI providers under their business/commercial terms, under which customer content is not used to train the providers' models:
- Anthropic — former recipient, removed from the code 2026-08-27 (§1). Under its Commercial Terms it did not train models on customer content and the customer owned outputs. Retained here because it describes the terms under which inputs were transferred while the integration was live; §2.3's open item applied to it then and is not cured by the removal.
- OpenAI — by default does not train on business/API inputs or outputs; API data is retained only briefly (up to ~30 days) for abuse monitoring, with zero-data-retention options available.
- Voyage AI and fal.ai — engaged for embeddings and image generation respectively.
- Microsoft (Azure OpenAI) — under the Azure OpenAI Service terms, customer prompts and completions are not used to train Microsoft's or OpenAI's models, and the service is operated by Microsoft rather than by OpenAI. ⚠️ Like the four rows above, this describes published service terms; §2.3 applies to it identically and its executed agreement is subject to the same open item.
2.3 Executed provider terms.
CIQRA's determination: the statements in §2.2 describe each provider's publicly published business/commercial terms. CIQRA has not verified within this workstream that a signed Art. 28 DPA and an executed zero-retention / no-training commitment are on file for each of the four providers actually in use — including Voyage AI and fal.ai, which earlier internal versions of this document and of the Subprocessor List omitted entirely. Until each executed agreement is located and recorded, the no-training assurance in §2.2 rests on published vendor policy, not on a contract CIQRA can produce. This is an open item, not a completed control.
2.4 Third-country transfer — now provider-by-provider, because they no longer share an answer. Because there is no gateway terminating AI traffic inside the EEA (§1), invoking an AI feature transfers the minimised input to the provider. Which country that lands in now depends on which provider serves the call:
| Path | Destination | Transfer status |
|---|---|---|
Text via Azure OpenAI (gpt-5-4-mini) | Microsoft Azure, ciqra-openai-prod, germanywestcentral | Intra-EEA, on the condition in §2.4.1 |
| US | Was a third country transfer while live — Art. 46 safeguards required for transfers already made; no new transfers occur | |
| Text/embeddings via OpenAI (direct) | US | Third country — Art. 46 safeguards required |
| Embeddings via Voyage AI | US | Third country — Art. 46 safeguards required |
| Images via fal.ai | US | Third country — Art. 46 safeguards required |
Art. 46 safeguards (SCCs) and a Transfer Impact Assessment therefore remain required for the AI path — for four of the five providers, and for every embedding call, because no Azure OpenAI embedding deployment is configured and embeddings still leave for Voyage or OpenAI. See DPA §11 and Subprocessor List §4.
2.4.1 🔴 The intra-EEA claim rests on the deployment's SKU, not on the account's region field, and CIQRA states the difference rather than glossing it. An Azure OpenAI account in germanywestcentral can serve a request from capacity outside the EEA if the deployment is a Global SKU; only the DataZone and Standard SKUs are confined. The two deployments on this account are not the same (measured 2026-08-26, AiOptions.cs:74-78 and Providers/AzureOpenAiChatClientFactory.cs:104-107, which quote the live account):
| Deployment | SKU | Data-residency limb | Called by the platform? |
|---|---|---|---|
gpt-5-4-mini | DataZoneStandard | EU data zone — capacity confined to the zone | Yes — this is the synchronous chat path |
gpt-5-4-batch | GlobalBatch | Global — capacity is not confined to the EEA | No. The factory raises rather than calling it (AzureOpenAiChatClientFactory.cs:120-127) |
So the intra-EEA row above is claimed for the gpt-5-4-mini deployment only, and it is claimed on the SKU. gpt-5-4-batch exists on the account and is a Global SKU; no personal data reaches it, because the platform refuses to call a deployment declared Batch at all. If that deployment is ever put into service, the intra-EEA claim does not extend to it and a transfer basis is required for that path — this is stated in advance so the change is a known one rather than a discovery.
Naming the region and stopping there would have been the easier sentence and the wrong one: "germanywestcentral" is where the account is, not a guarantee about where a Global-SKU request is served.
2.5 Roles. Where CIQRA acts as processor on Merchant data, these safeguards are mirrored in the DPA §13; the Merchant remains the controller and must not instruct AI processing of special-category or excessive personal data without its own lawful basis.
3. Transparency (EU AI Act Article 50)
3.1 Interaction disclosure. Where you (or a Storefront's shoppers) interact with an AI system (e.g. a chatbot), this is disclosed so it is clear you are dealing with AI, unless it is obvious from the context.
3.2 AI-generated content marking — mechanism present, with a stated limit. AI-generated or AI-manipulated content is marked in machine-readable form. What exists (measured 2026-08-09): generated image assets carry an IPTC Digital Source Type provenance marking — chosen deliberately over C2PA — (ciqra-saas/src/Ciqra.Api/Ai/AiProvenanceMetadata.cs:15-20); every generative operation stamps an ai:<operation> provenance tag on the produced asset (ImageStudioEndpoints.cs:332-333); and an AiDisclosureAck flag is recorded (ModelShotEndpoints.cs:303, migration 20260730004326_AiMarkingVerified).
Limit, in the code's own words (
ImageStudioEndpoints.cs:79-81): the platform "records provenance without being able to enforce a disclosure", because the surrounding merchant-facing copy is merchant-editable. CIQRA's determination: machine-readable marking of generated images is implemented; enforcement that a merchant does not strip or contradict the disclosure is not, and Art. 50(2) compliance therefore depends in part on merchant conduct governed by §4 and the AUP rather than on a platform control alone.
3.3 Timing. These obligations track the EU AI Act (Reg. (EU) 2024/1689) Art. 50, applicable from 2 August 2026. A provisional "Digital Omnibus" grace period may extend only the machine-readable marking duty (Art. 50(2)) to 2 December 2026 for generative-AI systems already on the market before 2 August 2026; the interaction-disclosure duty is not delayed.
CIQRA's determination: CIQRA plans to the 2 August 2026 baseline and does not rely on the Digital Omnibus grace period. The Omnibus text was at provisional agreement (07.05.2026) and not formally adopted as at this date; a compliance plan that assumed the deferral would be resting on an instrument that does not yet exist. This position must be revisited if and when the final text is adopted.
4. Your responsibilities & output use
4.1 Review before publishing. AI outputs can be inaccurate, biased, or incomplete. You are responsible for reviewing and verifying AI-assisted output before publishing or relying on it (e.g. product descriptions, translations, images).
4.2 Rights & lawful input. You must have the rights to any content you submit to AI features, and must not use them to generate illegal, infringing, deceptive, or harmful content, to produce unlabelled synthetic media where labelling is required, to impersonate, or to attempt to extract/reverse-engineer models or other tenants' data (see AUP §1). You must not remove, obscure or contradict the provenance marking described in §3.2.
4.3 Output ownership. As between CIQRA and you, you own the outputs you generate through the AI features (subject to third-party rights and provider terms), and you are responsible for their lawful use. AI output is provided "as is" with no warranty of accuracy or fitness.
5. Content safety & limits
CIQRA applies content-safety filtering to AI inputs/outputs and may block or limit AI usage that violates these terms, the AUP, provider policies, or law. AI features are not a substitute for professional (legal, medical, financial, tax) advice.
6. Changes
CIQRA may update these AI Terms, the providers used, and the features, on notice consistent with ToS §14; the Subprocessor List reflects current AI providers with change-notification. A provider migration — including the move to Azure OpenAI (§1.1) — is a subprocessor change and triggers the ≥30-day notice and objection right in DPA §5.
🔴 Status of that notice for the Azure OpenAI addition. The addition is a subprocessor change under this clause and the clause is not weakened by the fact that it has already shipped in code. A change notice has been drafted and is held for the provider's decision on whether and when it goes out; it is recorded in the commit that made this edit. This document does not state that the notice has been sent, and must not, until it has been. The addition of Azure OpenAI and the removal of Anthropic, OpenAI-direct and Voyage are two separate changes on this clause. 🔴 The second has now happened for Anthropic only (2026-08-27, §1.1). A removal is a subprocessor change under this clause just as an addition is, so it carries its own notice obligation; that notice is drafted and not sent, on the same footing as the addition's, and this document does not state otherwise. OpenAI-direct and Voyage have not been removed and no notice is owed for them.
Provision register (this document)
| Provision | Basis | Where |
|---|---|---|
| / legend | Replaced by the marker scheme note in the header | header |
| — | (B) declared position — executed agreements not verified; two providers were missing from the list entirely | §2.3 |
| — | (B) declared position — plan to the 2 Aug 2026 baseline, do not rely on an unadopted instrument | §3.3 |
| (not previously flagged) | (A) measured — provider inventory; no AI gateway | §1 |
| (not previously flagged) | (A) measured — Art. 50(2) marking mechanism exists, enforcement does not | §3.2 |
| (added 2026-08-26) | (A) measured — Azure OpenAI is wired and registered; the four earlier providers are still registered and are not removed | §1.1 |
| (added 2026-08-26) | (A) measured — the intra-EEA claim is limited to the DataZoneStandard deployment; gpt-5-4-batch is a Global SKU and is refused rather than called | §2.4.1 |
| (added 2026-08-26) | (B) declared position — the ≥30-day change notice for the Azure OpenAI addition is drafted and not sent; sending is the provider's decision | §6 |
Carried into force? No. This document carries 4 measured facts requiring no further input and 4 declared positions (§2.3, §3.2 limit, §3.3, §6 notice). Per the gate in 00-README §6, the (A) items are closed; the (B) items may remain visible at launch but must be visible, not silent.
End of AI Terms . See: Privacy Policy §4 · DPA §13 · AUP · Subprocessor List.