Embedded AI

Why

Giving a director, or a premium bank, conversational access to their own data has real usage value — but only if the language model can never write a free-form query nor cross a tenant, role, or access-type boundary. This process makes that access possible without ever opening it up to a data leak.

The same requirement holds for product help, for the public website assistant, for the Markets Assistant and for the learning of the risk model: each time, the AI explains, prepares or measures; it does not decide, validate, create or send anything. Every access to a piece of data goes through a rule enforced by the server, never through the text of the question.

How, in the application

The engine for questions about data

The conversational requêteur never lets the model generate SQL: it can only choose from a closed catalog of typed tools, one per access type (ERP and financing, financing only, or investor), with only one catalog loaded in memory for a given session. Every tool call passes through a single choke point that refuses any unknown tool name, rejects any scoping parameter the model might try to send itself (tenant identifier, user identifier, role), validates the rest against a strict schema, executes the query on a dedicated read-only connection, then verifies that every returned row genuinely belongs to the calling tenant — any foreign row fails the entire batch, not just the offending row. Every call is audited at this same choke point, never by the business code that processes the request.

The database connection dedicated to the requêteur holds only read rights, on a closed list of tables, with a strictly limited execution time — no sensitive table (users, payment configuration, signature, audit logs, KYB files) is ever accessible there.

The investor catalog continues to anonymize what it returns — supplier and buyer identity excluded, amounts and durations grouped by tier, sector anonymized by k-anonymity — even though the public market intended for investors has otherwise been closed: this catalog queries the historical data directly, independently of the closed screens, and therefore remains subject to this same anonymization.

Who has access to what

The access rule is carried by the account, never by the question asked. A single bubble, “Tauraco Assistant”, serves two modes; the ✨ “AI Assistant — your data” icon is the entry dedicated to figures; AI Analysis is the summary button of the dashboards and the bank cockpit.

A server-side configuration switch can reserve the bubble for the Pro plan: a question from a company without the Pro plan then receives a refusal (402, Pro plan required) and the bubble shows the invitation to upgrade. It is not enabled by default. AI Analysis strictly follows the Pro plan: the manager of a company on the Free plan does not receive it, server-side as in the application.

The bubble: product mode and data mode

Product mode. The server composes a product knowledge drawn from the built-in guide (modules, screens, plans read from the plan catalog, founders programme, help) and sends it with the person's profile (roles, plan, language — never a company or user identifier). No tools, no data: the assistant explains, gives the path in the application and points to the documentation; what it does not know, it says.

Data mode. When the company is Pro, the assistant on data is in service on the server (switch open, read-only connection configured) and the role derives an access type, the bubble queries the data through the requêteur engine: a closed catalog of typed read-only tools (13 for the company profile: sales, unpaid and overdue invoices, a customer's payment history, payables and main suppliers, cash position and forecast, financeable invoices, financing requests, offers received, disbursements and repayment schedule). The path is identical to the ✨ icon's: scoping parameters refused, strict schema, read-only connection, rows filtered by tenant, every call audited. A role refusal leaves no trace in the bubble, which simply stays in product mode. The ERP tools return amounts in the currency of each invoice, one row per currency when the company invoices in several currencies, and never add them together.

The bubble keeps the last 10 real messages of the conversation in memory (neither the greeting nor HTTP errors; a technical-problem or model-refusal message, returned as a normal answer, stays in it) to understand a follow-up question; it accepts up to 20 messages, 8,000 characters per message and 24,000 in total, the first and last message coming from the user. The conversation is not saved.

Caps, budgets and refusals

The day is the UTC day: counters and budgets reset at midnight UTC. The budget is checked before each provider call and consumed after it; it can therefore be exceeded by at most one provider call per request in progress: simultaneous requests all pass the check before being counted. A negative value cuts the assistant concerned — this is the emergency switch — and 0 keeps the default. If the counter is unavailable, the authenticated assistants stay served (the cap gives way, the error is logged); the public assistant does not, since its fail-closed global cap bounds the day's spending whatever the connection address.

Refusals are sentences, not technical errors: cap or budget reached, conversation too long, Pro plan required, service unavailable. A refusal by the model itself (“I can't answer this request”) and an answer cut short by length (“incomplete answer”) are returned as they are, with no invented text.

Escalation: speaking to someone

No assistant forwards a conversation: none is kept. In the application, the bubble points to the “Help & support” screen and the team's address, when it cannot answer or when asked. On the public website, the assistant points to the contact form, the only human channel it offers.

The public website assistant (Aïssa)

Aïssa, presented as an AI assistant, answers tauraco.io visitors about plans and pricing, the founders programme, tenders, financing and sign-up, from a knowledge copied from the public pages and the plan catalog. She accesses no account, file or company data, and keeps no conversation. She states explicitly that Tauraco is not a lender, does not collect capital and that disbursement is made by the institution. The widget is mounted only on five tauraco.io pages (home, financing, support, about, contact): never under tauraco.ai, nor on sign-up, sign-in, the accounting-firm space or legal pages. She accepts at most 12 messages (the widget sends 10), 1,500 characters per message, 12,000 in total, in French or English.

The Markets Assistant: module rights

Five one-shot assistants (tender notice, CRM opportunity, application, Collateral dossier, search) prepare material to validate, with cited sources and uncertainties; none creates or sends anything. From a saved object (opportunity, application, dossier), the assistant requires what the source module's read route requires: the module flag for the company (otherwise 404) and access to the module (otherwise 403), company administrators passing the second gate by default; an assistant user therefore cannot read through the AI what the module refuses them directly. The “pasted text” mode reads no other module. Before anything is sent to the provider, e-mails, phone numbers, IBANs, legal identifiers and known person names are masked with stable tokens, restored in the answer; this masking relies on rules, not on a guarantee. The company's call log keeps identifiers, token counters and cited passages in their masked form. The company's daily budget is checked before each call; a call abandoned at the timeout counts a cautious estimate of its tokens against it, for lack of a response to measure. The module's default provider is an offline simulation; the real engine is set by configuration, and the “Engine” line on the screen says which one answers.

Learning of the risk model

What the canary learns: a threshold on a single variable, the amount including tax, from the invoices of a tenant that the team has labelled “risky” or not (risk label). The threshold is the midpoint of the two classes' averages; the direction (high or low amount = risky) follows from it. The measures — accuracy, precision, recall, F1 and AUC — are computed on the validation and test sets. It is neither a language model nor fine-tuning, and it learns nothing from the assistants' conversations. The threshold only holds in one currency: a dataset in several currencies is stopped with its reason, and a model does not score an invoice in another currency.

The gate: a model produced is registered as “experimental”; every promotion is manual and moving to “active” requires AUC ≥ 0.65, F1 ≥ 0.60 and precision ≥ 0.55. Direct activation, reserved for platform administrators, does not go through this gate but is traced.

Provenance: only a “production” provenance, declared by staff when the dataset is created, makes a canary promotable. Without a declaration, or for the demonstration tenant — whatever its configuration says —, the job ends SYNTHETIC_NON_PROMOTABLE with its reason: no model is produced. This result is expected on demonstration data, and it turns health yellow, not red. As long as the way to declare a client tenant's dataset “production” is not decided, no model learned from real data is promotable.

Isolation: a dataset keeps only the invoices of its own tenant; a model scores only the invoices of the tenant whose dataset learned it (the others receive the deterministic fallback rule); an invoice's predictions are readable only by its tenant; the model registry is readable only by staff (ADMIN, OPS, SUPER_ADMIN); training is a platform function, launched only by ADMIN and SUPER_ADMIN (OPS creates and follows jobs). Launch, completion, promotion and rollback actions are audited under the actor's tenant.

Supervision: the training process regularly signals that it is alive, read by system health; at start-up, it takes up again the launches left without an outcome; it trains only the jobs that were launched and are waiting (a request aimed at a job that is already finished, cancelled or unknown is filed away without being replayed, so that a history is never rewritten); and it marks as failed any “running” job with no sign of life for five minutes. The health of the “last training” is green for REAL_CANARY_PASSED, yellow for a pending, queued, running or SYNTHETIC_NON_PROMOTABLE job, red for FAILED, BLOCKED_NO_DATA and CANCELLED.

Safeguards

• A platform administration role can never use the requêteur — access is explicitly blocked before an LLM call is even considered, as is a profile with conflicting roles.
• Access to data is subject to a premium-subscription check, verified before any spend on a model call — every refusal of the ✨ icon, whether by role or by subscription, is audited before the error is returned; it does not consume the quota.
• The list of accessible tables exists twice, once at the database-role level and once at the application level — the two must match, and one acts before the other is even consulted.
• The client can only send user and assistant messages, the first and last from the user, with no empty message: no instruction passes through the conversation, and a last assistant turn cannot whisper the answer.
• The product knowledge contains no company data: it is the same for everyone, and the profile sent carries no identifier. Tool results go back to the provider without a tenant identifier.
• No assistant reads a server file at run time: their knowledge is copied into the code and checked by tests against the sources (guide, plans, public pages, editorial safeguards).
• The artificial intelligence service is an external provider, Anthropic (Claude models), called with a primary key then, if it is refused, a backup key. Each call writes a usage line (route, model, tokens, duration) without the content of questions or answers and without an IP address.
• Their instructions forbid the assistants from giving a rate, ranking offers or promising financing: these conditions come from the bank, never from the platform.