Questions & Answers
Frequently Asked Questions
Truffalo turns the communication your sales team already has — mailboxes, chats, shared documents — into structured business records and prioritised, actionable signals, without asking anyone to type data into forms. Because that means Truffalo reads real business communication, questions about data protection, AI governance and security are the right questions to ask. This FAQ answers the ones we hear most often.
1. GDPR & data protection
Truffalo processes the business communication you explicitly connect: selected mailboxes, chat channels, and document folders. From these it derives business records — companies, contacts, deals — and short, evidence-based signals for your team. You decide, channel by channel, what is connected; nothing is ingested from a source you have not configured. It is a deliberate opt-in decision your organisation makes.
Truffalo ships with a dedicated GDPR programme rather than bolted-on compliance features. It includes:
- consent management,
- support for data subject requests (access and erasure),
- per-tenant data retention rules with an automated monthly retention process,
- tamper-evident audit log: every privacy-relevant action is recorded in a hash-chained, immutable log, so the record of what happened cannot be silently altered — by anyone, including us.
When a data subject exercises their rights, the platform supports producing the relevant data and executing erasure across the derived records. Erasure is designed to be reliable by construction: the process is idempotent and resumable, meaning an interruption can never leave data half-deleted without the system knowing — it completes, verifiably.
Retention rules are defined per client organisation, and an automated process runs monthly to evaluate stored data against them. Actual deletion is activated deliberately by an administrator — a two-step design chosen so that irreversible deletion never happens as a silent side effect of a configuration default.
Three properties help here:
- The hash-chained audit log gives you a tamper-evident record of privacy-relevant events.
- Every AI-generated signal carries its evidence and a stored scoring snapshot, so any conclusion the system drew can be traced back to what it was based on.
- AI-discovered companies, contacts and signals become business records only after a person confirms them.
Truffalo's production environment runs in the European Union: all components of the solution — the application, the database, file and document storage, and document generation — run on truffalo.ai's own infrastructure in the Hetzner cloud (EU). The one category of processing that leaves this infrastructure is AI model inference, and section 2 explains how your organisation controls which models are used for it.
2. AI models & EU AI Act
Truffalo is deliberately not built on a single AI model. The platform maintains a continuously synchronised catalogue of roughly 190 models across providers, and every AI task in the product (parsing, signal classification, discovery, chat, and so on) is resolved through a governance layer that decides which model handles it. All AI traffic leaves the platform through one controlled gateway — a single, auditable exit point.
The current offering is the catalogue of the Vercel AI Gateway: roughly 190 models spanning the major commercial providers. We are additionally evaluating EU-based model providers whose models run in EU clouds; this is under evaluation and not yet a committed part of the offering.
Truffalo offers BYOK (bring your own key) functionality, so a client can bring the key to access the provider and model they want used within Truffalo.
Yes. Model assignment is configured per client organisation and per use case, and changing it is a configuration change, not a software release. The governance layer resolves in strict order: an emergency kill switch, then your organisation's assignment, then platform policy, then a safe default. End users cannot override this — a model choice smuggled in by a client application is deliberately ignored.
Truffalo itself never uses your data to train AI models. When an item is analysed, data is sent to the assigned model provider for inference only — to generate that one response. Truffalo always has Zero Data Retention (ZDR) settings ON when using LLMs. Whether a provider may retain or use API data beyond that is governed by the provider's own terms; the major commercial providers' API terms exclude training on customer API data. Because your organisation controls which models are assigned (see 2.2), processing can be restricted to providers whose terms your DPO has approved.
AI usage is metered call-by-call in a cost ledger, and each automated process carries a monthly spending cap per client organisation. If a cap is reached, the process pauses automatically rather than overspending. Independently, the platform aggressively filters what reaches the AI at all: items classified as low-relevance never trigger a second AI analysis — in practice about three quarters of newly ingested items stop there.
No, and this is a design principle, not a setting. AI outputs — a discovered company or contact, a recommended action — are candidates that a person accepts or rejects; where the system updates an existing record directly (for example, advancing a deal's stage based on new communication), the change carries a full audit trail of what was changed and why. Even the platform's internal AI agents operate with strictly read-only access to your data: they can look things up, they cannot change anything.
Truffalo's architecture aligns with the AI Act's core expectations for deployed AI systems: human oversight (every output is human-confirmed), transparency (every signal carries its evidence and a stored scoring basis), traceability (auditable model governance and per-call records), and controllability (per-tenant model assignment and a kill switch).
3. Security & isolation
Truffalo is multi-tenant by construction: every business record carries the identity of the organisation that owns it, and every read and write is scoped to your organisation. Crucially, this scoping is not left to individual developers to remember — all database access is funnelled through a single data-access layer where organisation scoping is applied in one place, and this rule is mechanically enforced in our development process (automated checks block code that tries to bypass it).
Access within your organisation is role-based, and visibility is personal by default. AI-generated signals are assigned to the people they concern — the account manager on the deal, the owner of the relationship — so each user sees their own queue, not an organisation-wide firehose. A regular member requesting “everything” receives their own items; broader configuration (sources, members, delivery, budgets) is reserved for organisation owners.
Platform operation is a separate, independent role system: being a Truffalo operator conveys no privileges inside your organisation's workspace, and vice versa. Operational access is limited to platform administrators for support and operations, and privacy-relevant administrative actions are captured in the tamper-evident audit log described in section 1.
Source credentials are stored per organisation and encrypted. Connections are configured explicitly per channel, and access tokens for machine access (such as the read-only AI agent interface) are ephemeral, expiring after one hour.
Only through channels your organisation has explicitly authorised. When the platform discovers it could reach a chat (for example a Telegram group), that chat is recorded merely as a candidate — reachability is never treated as permission. Data flows only after an organisation owner explicitly enables the destination, which is recorded with who enabled it and when. Every delivery is written to a ledger, and delivery rules default to off and to the quietest useful setting.
4. Processing your communication
Each item passes through a pipeline: it is fetched from the connected source, analysed once by an AI model into a structured summary with business-signal classifications, scored against a fixed, committed scoring table, archived, and — only if relevant enough — turned into an actionable card for the right person. The scoring is done by the platform, not by the AI: the model may claim a signal only with evidence, and claims without evidence are discarded.
No. Actionable signals are routed to the people they concern (see 3.2), so ingestion breadth does not translate into visibility breadth. Organisation owners additionally control which parts of the product are enabled at all for their teams.
Several controls exist today. Scope starts at the source: you choose which mailboxes, channels and folders are connected, and sent mail is excluded unless you opt in. Specific companies or counterparties can be blocked, which suppresses them from discovery permanently — a blocked entity never resurfaces, even on re-scan. The parsing behaviour itself is policy-driven and tunable per deployment. And the relevance gate means low-signal content — including most personal chatter — never becomes a visible card.
Beyond these structural controls, exclusion rules can be tailored to your organisation. A rule is a human-written, plain-language description of what must not be processed — for example: “skip anything that is an internal HR matter, relates to the works council, or is clearly a private conversation between colleagues.” Items matching such a rule are skipped completely: they are not parsed into records, generate no signals or cards, and are never surfaced to anyone in the product. Because rules are plain text rather than code, they can be adapted to your internal policies — and reviewed word-for-word by your DPO or works council — without a software change.
Every ingested item is scored against a 40+ category taxonomy of business signals. Items that score in the lowest band — spam, notifications, routine noise — are archived but never surfaced and never receive further AI analysis. Measured in production, about 75% of newly ingested items stop at this gate.
A person rejects it — that is the normal, designed-for path, not an exception. Rejected signals do not become records. If an item is re-analysed, the new result supersedes the old one in place, so there is exactly one current interpretation of any source item, with an audit trail of how it got there.
Free CRM functions include management of clients, contacts, deals within the sales funnel, the product catalog, orders and tasks. Users can create and edit them manually. The system also creates the system of records automatically from the connected sources (as per the selected package).
Write to us — we answer in writing
Including anything your DPO or works council needs on paper.