What runs underneath Ediccio. Disclosed.

Ediccio's model layer provides two capabilities: an extract capability that turns a raw signal into structured profile observations, and an embed capability that turns text into vectors for similarity search. The extract capability can be pinned per tenant (an Ediccio operator setting, not a customer control); embed cannot. Every tenant without a pin runs on the default composition. The table shows the currently pinned versions; version updates within the same model family ride the silent-upgrade rule under Change notification below.

The fallback is composed: the primary serves every request, and the secondary takes over only when the primary fails with a transient provider error. Both models are measured independently against the same golden set, and the composition is qualified as a whole (the Quality section below).

A better model is a silent product upgrade. You never choose a model, and a model name never appears on a pricing page. We measure quality, and when a change improves it, we roll it out without changing the contract; changes to the disclosed default follow the 30-day notice under Change notification below.

Ediccio's product processes tenant data exclusively in AWS EU regions. Tenant data lives in eu-west-1 (Ireland). The extraction calls use EU cross-region inference profiles (eu. prefix), so Bedrock may run them transiently in another EU region (each one is named in the Models and regions table under Sub-processors below); the embedding calls run in eu-west-1. Inference does not leave the EU under the default configuration.

The residency claim covers transport, not just storage: the API endpoints (mcp.eu.ediccio.ai, with mcp.ediccio.ai as an alias) terminate TLS in eu-west-1 on a regional front, so tenant data is decrypted only in the EU, including in transit. The data plane carries no CDN.

Two non-EU exceptions are AWS-contract-driven and hold no tenant data: Amazon CloudFront (global edge, serves the marketing site, the customer dashboard's static files and our own operator console, whose traffic is our own controller-side data, prospects and our legal inboxes, never tenant data) and AWS Certificate Manager + Route 53 (us-east-1, DNS + cert plane; CloudFront requires its certificate to be in us-east-1). A request to any of the three may be processed at a CloudFront edge outside the European Economic Area in transit, as our privacy policy states. These are disclosed in the sub-processor list and processed under the same AWS DPA umbrella.

If a customer brings their own model (designed, not yet built; see below), the region of that provider would be theirs to control and would be recorded in the per-tenant DPA addendum.

Our own channels. The EU-only claim above is about the product. Our own sales and support channels are different: prospects who message us on WhatsApp are processed by Meta Platforms Ireland Limited as our processor, with Meta Platforms, Inc. (United States) as sub-processor under the EU-US Data Privacy Framework and, as fallback, EU Standard Contractual Clauses; WhatsApp Cloud API messages are not end-to-end encrypted. This is the only flow in which personal data we control reaches a sub-processor outside the EU; the CloudFront edges above may also process requests to the site and the console in transit outside the European Economic Area, as our privacy policy states. Neither touches tenant data. Email is sent via Amazon SES in eu-west-1.

Every extraction model that ships is measured against the same golden set: 30 rows across six dimensions (intent, pain, sentiment, preferences, traditional fields, adversarial). The harness and golden set are available for customer review on request, and every number below is reproducible from them with a single command per configuration.

Mistral standalone is below the qualification threshold and is not customer-selectable. It serves only as the secondary inside the fallback composition; the composed fallback matches the primary's score because the secondary only runs when the primary fails. Under nominal load, Claude carries every request.

The two recall misses on the default configuration (one intent, one traditional field) are semantic disagreements between authored golden labels and model readings, not extraction failures. Per-dimension F1 is 1.000 for pain, sentiment, and preferences.

Ediccio acts as a processor under Article 28 GDPR (and equivalent provisions of the UK GDPR, Swiss FADP, and analogous frameworks). The customer is the controller; they bring the end_user_id of every subject. Ediccio's processor is Amazon Web Services (contracting entity Amazon Web Services EMEA SARL, with Amazon Web Services, Inc. as co-party under the AWS GDPR Data Processing Addendum), EU regions only; every service in the product data plane runs within it. AWS's own sub-processors are published on its sub-processors page, and we subscribe to its change notices. The models we run inside Bedrock are licensed by Anthropic Ireland, Limited (Claude) and Mistral AI (via AWS); AWS documents that model providers have no access to Bedrock logs, prompts or completions, and we pin only models served with zero data retention. The full per-service breakdown lives in the DPA sub-processor register, available on request, so this page stays at the entity level and does not churn on every internal architecture change.

Amazon Bedrock does not use our prompts or completions to train models and does not share them with model providers. We pin only models Bedrock serves with zero data retention (Claude Sonnet 4.6, Pixtral Large, Titan Text Embeddings V2), so no prompt or completion is written to durable storage by AWS. Bedrock runs automated abuse detection; for our models and text-only inputs this stores no content. Model invocation logging is not enabled.

Models and regions. The three pinned model IDs and the regions AWS publishes as destinations for their inference profiles. Last verified 2026-10-18.

Milan (eu-south-1) and Spain (eu-south-2) are opt-in regions that a profile may route to even when they are not enabled in our account, so they are listed. The destination lists are AWS's, read on the date above.

Ediccio commits to give controllers at least 30 days' prior notice of any addition or replacement of a sub-processor, via the contact established in the DPA. The per-service register (which AWS services run where, kept in lockstep with the architecture) lives in the customer-facing DPA package; the architecture decision records behind this page are shared with it on request.

A data-subject erasure is a hard physical delete of the subject's rows from the tenant database, accompanied by a PII-free audit record. There is no crypto-shredding (the bytes are removed) and no soft-delete-then-purge (the operation is atomic). The audit record names the request, the requester role, and a salted hash of the subject identifier, never the subject's identifier itself.

• Erasure SLO. 30 days from the verified request to subject rows no longer reachable in any live store. Active backups are honoured at the next backup-rotation boundary, within the same SLO.
• Backups. 7-day point-in-time recovery; no longer-lived snapshot schedule. Subject erasures age out of backups at the rotation boundary, inside that window.
• Operational logs. Retained 30 days, then auto-purged. Subject identifiers (end_user_id) and raw signal content are never written to logs; PII is scrubbed at source.
• Bedrock telemetry. Bedrock does not use prompts or completions to train models or share them with model providers; the pinned models are served with zero data retention (Sub-processors above), and model invocation logging is not enabled.

DSAR endpoints (POST /tenants/{tenant_id}/subjects/{end_user_id}/erasure, POST /tenants/{tenant_id}/subjects/{end_user_id}/export, GET /tenants/{tenant_id}/dsar/{request_id}) are exposed on the Management API. The customer's Consent Management Platform (OneTrust, Transcend, Ketch, or in-house) is the system of record for consent and calls these endpoints from its workflow. We integrate with CMPs; we are not one.

Most disclosures stop at architecture. This one doesn't, because architecture without verification is a guess. Ediccio's verification gates run on two cadences. The static gates (lint, type checks, the unit suite, and the tenant-isolation gate) run on every pull request, on every change to the main branch, and daily. The gates that exercise live inference against the golden set (live Bedrock, not mocks), the end-to-end round trip, failover, and the data-subject-rights flow are run by an operator and logged, each run with its date; the Quality table above shows the date of the last qualification run per configuration.

Cadence. Static checks run on every pull request, on every change to the main branch, and on a daily cron; the tenant-isolation gate runs on every pull request and every change to the main branch. The gates that exercise live inference, and the data-subject-rights gate, run as an operator-initiated, logged workflow; the dates in the Quality table are the dates of those runs.

Audit trail. Operator-initiated verification runs are recorded in a dated log kept in version control, available on request alongside the DPA package. As that history accumulates, the availability target in the Availability section below becomes reportable from the log itself, not from an estimate.

Availability and fallback rate are not measurable yet. The verification log needs a sustained stretch of clean history before the numbers stop being noise; the published target lands in this section once the log can back it.

The temporary line: Ediccio is in private beta, so production availability is not yet reportable. The verification cadence above is the closest proxy until then.

Profiles and signals are AI-generated inferences from text, delivered with confidence scores to your systems over MCP. Ediccio does not interact with your end users directly, and it does not process biometric data, so it is not an emotion-recognition system as the EU AI Act defines one (Art. 3(39): inference of emotions from biometric data). Sentiment here is a property extracted from written conversation, like intent or a preference. The transparency duties of Art. 50 that attach to systems interacting with people sit with the agent you build; what Ediccio owes you is inference clearly marked as inference: every observation carries a confidence score and a machine-readable provenance marker on every surface that emits profile content.

Intended purpose. Ediccio builds a deep profile of a business's own customers, prospects and product users from the conversations that business already has with them, so that the AI agents in its product (sales assistant, support copilot, customer-onboarding bot, customer-success agent, marketing agent that messages customers who can reply to it) can personalise those conversations. It is not intended for use in, or as an input to or part of, systems that evaluate people for credit, insurance or public benefits, for emergency triage, for hiring or at work, or for education or training, nor in law enforcement, migration, justice or elections. It is not for profiling a business's own workforce, job candidates, students, trainees or patients. A dimension, field or journey definition that names a special category of personal data or a criminal record (GDPR Art. 9 and 10) is refused before it takes effect.

The model layer is interchangeable by interface, a standing architectural commitment, and that much is built: the boundary is a capability contract, the qualified substrates sit behind a registry, and a tenant can be pinned to one of them for extraction. Embedding cannot be pinned: every tenant's stored observations are embedded on the same single model, and search queries are embedded with it too.

What is not built is the customer-facing half. Pointing that boundary at a customer's own endpoint, so that their provider would be their own processor rather than our sub-processor, is designed and not yet shipped, and so is the model-cost pass-through that would price it. A customer who needs to pin a specific provider today, for sovereignty, for an existing enterprise contract, or for cost, should raise it with us rather than read it off this page.

The contract is capability-shaped (extract, embed), not provider-shaped. There is no streaming, no tool-calling, no chat surface inside Ediccio's model boundary. Those are deliberate non-features; the boundary is narrow on purpose.

Changes to the disclosed default models or to the sub-processor set are announced to controllers at least 30 days in advance, via the contact established in the DPA. Model-version changes within the disclosed default (Anthropic's Claude moving to a newer Sonnet release, for example) are silent product upgrades unless a different model becomes the disclosed default; if one does, the 30-day rule applies.

A dated diff log of default-model changes lives under this page as it accumulates.