Trust Center
AI and your data
Four guarantees, the path a request takes from a person to a provider and back, the boundary between infrastructure and models — which is what makes the sub-processor list short — and EU AI Act transparency across all four paragraphs of Art. 50. Where a statement rests on something you cannot open, that is said next to it.
Four guarantees
Each is either a statement that holds without an agreement you have not seen, or a statement carrying a marker for what is still missing.
-
Your data does not train shared models
We do not use your content, your prompts or the output generated for you to train, fine-tune or improve any generative model — ours, a shared one, or a third party’s — and we do not hand them to anyone for that purpose.
- The inference provider is bound by the same restriction through the terms of our agreement with it. We provide those terms on request. Awaiting confirmation: the terms of our agreement with the inference provider, which nobody outside the company has seen
- What we do use: aggregated, de-identified statistics — counts, latencies, error rates — to operate and improve the service, provided they cannot be attributed to you or to any data subject.
-
AI access is bound by your tenant’s permissions
An AI feature runs inside your tenant and within the same roles and permissions as a person: it does not see what the user it acts for cannot see, and it does not reach another tenant’s data. Awaiting confirmation: that an AI feature acts within the role of the user it is acting for
- The technical isolation model — exactly how the environments are separated — we describe on request under NDA rather than publishing it.
-
Only agreed context goes to inference
Only the context agreed for a given feature is sent to inference, not the contents of your tenant as a whole. Awaiting confirmation: the context-selection procedure and the document that records it
- We do not publish a detailed description of exactly which fragments reach the model for each feature — and we will not describe it approximately.
-
The AI provider running inference is named
The provider that runs inference for the built-in AI features is named on the published sub-processor list — with its purpose, the categories of data and its location. The model families it executes are named separately from it — they are not rows of the register.
The sub-processor list
Where a request goes
From a person’s action to the audit log. The steps with no published document behind them are marked in the diagram itself.
- The user
A request starts with a person acting inside your tenant — a question in a panel, a button in a module, a generation they started.
- Sintora AI
The platform’s AI layer takes the request. Modules and industry solutions run inside your tenant on a shared data model rather than as separate deployments — and the AI features reach that same data rather than a copy of their own.
- Identity, tenant and permission checks
Who is asking, which tenant they belong to and what that role is allowed to do. Tenant isolation and the role model are the same ones that apply to any other action on the platform.
- Context selection and minimisation
The context for that feature is then assembled — only what is agreed for it, not the contents of the tenant as a whole.
How the selection is performed and what it excludes is not published. Awaiting confirmation: the context-selection procedure and the document that records it
- The agreed AI provider
Scaleway SAS
AI inference using agreed models on Scaleway infrastructure
Location: France / EEA Awaiting confirmation: the specific region
- The response
The response comes back to the person who asked for it. It is a draft rather than a decision: a person acts on it, and the Terms say plainly that output can be incomplete, or confidently plausible and still false.
- Audit
Significant actions inside your tenant reach the audit log on paid plans.
The log covers significant actions inside the tenant on paid plans. Awaiting confirmation: which events of the AI features reach it
Infrastructure and models are different things
A sub-processor is a party your data reaches. The infrastructure provider executes a model’s weights on its own hardware — your prompts, the context and the response pass through it, so it is a sub-processor and it is on the list. The model’s developer receives none of that, so it is not. That is a distinction rather than an omission.
Scaleway SAS
AI inference using agreed models on Scaleway infrastructure
Location: France / EEA Awaiting confirmation: the specific region
This is the party the data actually reaches, so it is a sub-processor and it stands on the list together with its transfer mechanism. Replacing or adding one happens on the same notice as any other sub-processor.
- Mistral
- Llama
- Qwen
- Kimi
A model is not a sub-processor where its weights are executed by the infrastructure provider and the model’s developer receives no customer data. So the families are named here rather than as rows of the register.
Which of these models are wired up right now is a separate question from which families are agreed. Awaiting confirmation: the current inference configuration
We do not publish version numbers, and not because keeping them current is a chore: a version number changes none of the lawful basis, the transfer mechanism, the membership of the sub-processor list or the prohibition on training. The legal entity that matters for the first two is the infrastructure provider on the left. That a version changes faster than any page is true too, but it is the second reason.
A provider you connect yourself
Some features — Companion is the one that works this way today — call a provider you connect, through your account.
Where a customer connects an AI provider through their own account, the nature of the processing relationship depends on that customer’s configuration and their agreement with that provider. Sintora does not use an account of its own for that inference route.
DPA → AI features and model trainingEU AI Act transparency
Regulation (EU) 2024/1689. Chapter IV — transparency, which is Art. 50 — has applied since 2 August 2026; the prohibited practices of Art. 5 and the AI-literacy requirement of Art. 4 came earlier, on 2 February 2025. Below are the four paragraphs of Art. 50 by name, our position on the prohibited practices, human oversight, and Art. 4, which we leave open.
-
Art. 50(1) — a person must know they are talking to an AI
Systems that interact directly with people must be designed so that the person knows they are interacting with an AI system. The duty does not apply where that is obvious to a reasonably well-informed person.
The duty under this paragraph is ours. We are the provider of the AI features we offer under our own name, and designing them so that a person knows they are talking to an AI is the provider’s to do. Separately from that, our agreement with you recognises that depending on how you deploy a feature you may carry transparency duties of your own under Art. 50, and that we provide the product disclosures and the means to support you in discharging them. Those duties arise from the Regulation rather than from our text, and the agreement does not move them onto you: the duties of a deployer are allocated by Art. 50(2)–(4) themselves, not by our drafting. Art. 50(1), which this card is about, binds the provider and places nothing on a deployer at all. There are two such places on this website and they are built differently. The first is the adviser panel: it is always present, and the AI conversation inside it is switched on by an environment variable that is not set on the deployed site; the disclosure lives in that conversation — the screen that is the only way into it prints «you are talking to an AI agent, not to a person» in both languages, and it cannot be bypassed. The second is the reply the contact form prints after a submission: there the disclosure is a caption directly under the reply itself, inside the same condition, so there is no state in which one of them renders without the other. A gate before the output and a caption under it are different artefacts, and each stands where the person it is for will meet it. Both are named under this card. In our internal register this duty stands as an undertaking rather than as discharged: the disclosure is written, and we cannot show you a deployment on which it can be watched. Until 08.09.2026 this read «the panel only appears where the corresponding environment variable is set, and on the deployed site it is not — so there is no AI interaction here today that would need disclosing». The first half confused the panel with the chat and was refuted by this page’s own markup; the second stopped being true the second the variable was switched on.
Covers: The AI adviser on sintora.ai, The personalised reply in the contact form, Chat — the AI inside a conversation, Synapse, Video Email Prospector, Companion, Web Pages — the agent that builds and publishes, Sintora Meetings — the after-call analysis
Unresolved for: Service Desk — triage and draft replies
DPA → AI features and model training -
Art. 50(2) — generated output must be marked machine-readably
A provider of a generative system ensures that its output is marked in a machine-readable format and detectable as artificially generated or manipulated. This is a provider duty — ours, not yours.
We do not carry this today, and we say so plainly. A visible label is one thing; machine-readable provenance through a standard such as C2PA Content Credentials or an IPTC DigitalSourceType field is another, and it is what this paragraph asks for over and above the visible label. We undertake to carry one of the standards. No artefact we publish would let you verify that it is carried today, and nothing we have published names a standard or a date. Awaiting confirmation: the provenance standard, the date it applies from, and a file you can see it in
Covers: Content Hub, Video Email Prospector, Web Pages — the agent that builds and publishes
Unresolved for: Synapse, Companion, The personalised reply in the contact form
Video Email Prospector → disclosing generated media -
Art. 50(3) — emotion recognition and biometric categorisation
A deployer of an emotion recognition or biometric categorisation system informs the people exposed to it. Art. 3(39) defines an emotion recognition system by reference to inferring emotions from biometric data.
We provide no biometric categorisation system: there is no face recognition in the product, no voice identification and no inference of sensitive traits from biometrics. Nor do we claim emotion recognition. Until 08.09.2026 this site showed a sentiment readout in its call results — «Sentiment» in the scenario mock-up and «Mood» on the Sintora Meetings product page, both in the metric row beside the audio and video recording strips. By the owner’s decision of 08.09.2026 it has been removed: the site no longer offers or advertises a sentiment or mood readout on call results. That is a statement about this site, and we deliberately make no wider one here. Whether the deployed product computes such a readout, and on what basis, is an open question for the owner; our internal AI system register holds it open, and this change does not close it. Awaiting confirmation: whether the deployed product computes a sentiment readout at all, and if so whether from text or from voice
Covers: No system in the inventory currently records a duty under this paragraph.
Terms → AI features and your obligations -
Art. 50(4) — deep fakes and text on matters of public interest
A deployer of a system that produces a deep fake — an image, audio or video a person could take for authentic — discloses that the content has been artificially generated or manipulated. The same holds for text published to inform the public on matters of public interest — subject to the carve-out the paragraph itself contains: the duty does not apply where the content has undergone human review or editorial control and a person holds editorial responsibility for the publication. Art. 50(5) fixes when: at the latest at first exposure, clearly and accessibly.
This is a deployer duty — yours — and no page of ours can discharge it for you. Our part is to build the product so that it carries the disclosure for you. One product already sets this out as a section rather than as small print: the Video Email Prospector page publishes four undertakings about what a campaign result will carry, each marked as awaiting confirmation, and names the machine-readable-provenance gap separately. On this website the notice about generated illustrations is in the footer of every page — since 07.09.2026 including the four demo and request-access screens, which build a frame of their own and until then carried no disclosure at all. It is a notice about the site rather than an inventory of its files: the «AI-generated image» caption stands beside the picture itself where the picture shows a person, and deliberately does not stand under decorative graphics. Awaiting confirmation: a finished campaign result showing where the disclosure actually lands
Covers: Video Email Prospector
Unresolved for: Content Hub, Web Pages — the agent that builds and publishes
Video Email Prospector → disclosing generated media
Prohibited practices — Art. 5
Every system in the inventory is screened against Art. 5 by name. The lists below are not typed here: what we deny and what is still an open question are both built out of the screenings themselves, so the sentence cannot drift from the register. Where an answer is not yet in, it stays a question rather than becoming a denial. Our Terms separately prohibit you from using our AI features for any of the prohibited practices. Awaiting confirmation: answers to the screening questions the inventory still holds open
We neither provide nor build: techniques designed to work below conscious perception or to manipulate behaviour, exploiting a vulnerability of age, disability or socio-economic situation, social scoring, predicting a crime by profiling a person, untargeted scraping of facial images, real-time remote biometric identification.
An open question rather than a denial: inferring emotions in the workplace or in education, biometric categorisation by sensitive traits.
Human oversight
Where AI proposes, scores or flags something, the result is a draft rather than a decision: a person reads it and decides what to do with it. The owner’s decision of 08.09.2026 makes that the product’s base rule: the AI recommends and a person decides. That does not describe one feature, and saying so matters more than not. The AI node in Automations classifies an event inside a workflow fired by an event rather than by a person; what happens with each of its answers is set by whoever built the workflow and switched it on. Human oversight there sits at the level of the workflow rather than of each run, and that is their choice to make. The Terms carry the rest as an undertaking: AI output can be incomplete, or confidently plausible and still false, and you are required to keep meaningful human review over decisions that affect people. Awaiting confirmation: which features can act with no person in the loop, and the limits on what they may do
AI assists. Humans remain accountable.
AI literacy — Art. 4, an open item
Art. 4 of the AI Act requires providers and deployers to take measures towards a sufficient level of AI literacy among the staff working with these systems. It has applied since 2 February 2025 — earlier than the transparency chapter, and that belongs here rather than behind a date in the section heading. We publish no programme, and while there is none we do not claim one. The item stands open not because the duty does not reach us, but because there is nothing to say about it today beyond this.
The AI system inventory
Everything this section states rests on an internal inventory of AI systems: the list the risk assessment, the Annex III classification, the Art. 5 screening and the Art. 50 duties are read from. It does not cover every feature of the platform — the products not yet screened are listed in it separately, with a reason and a place in the queue, and the automated check that accompanies every change fails if a product whose catalogue copy names AI or an agent is in neither list. We do not publish the inventory itself: it holds internal assessments, open questions and the names of the people who answer them. Every record in it carries:
- the system
- our role and who deploys it
- what it does
- its intended purpose
- reasonably foreseeable misuse
- the risk tier
- the applicable Art. 50 paragraphs and how far each duty is carried
- the Art. 5 screening
- the Annex III screening
- human oversight
- the route to a model
- the date it was last checked
- the date of the next review
What we do not publish
What we provide on request, or do not provide at all, with the reason for each entry.
-
Exactly what context reaches the model
We do not publish a detailed description for each feature, and we do not give an approximate one either. -
Model versions and the current inference configuration
We do name the model families; version numbers we do not, and the reason is not that keeping them current is a chore: a version number changes none of the lawful basis, the transfer mechanism, the membership of the sub-processor list or the prohibition on training — that is, none of the answers people come here for. That a version changes faster than any page is true too, but it is the second reason. A separate question is which models from the named families are wired up right now: that is not a decision to withhold, it is a fact standing in the register as awaiting confirmation. -
An independent assessment of the AI features
We have not commissioned one. When we do, a summary will be available under NDA — as with a penetration test summary, which we do not have yet either.