Lo que hay debajo de Ediccio. A la vista.

La capa de modelos de Ediccio ofrece dos capacidades: una capacidad extract, que convierte una señal en bruto en observaciones de perfil estructuradas, y una capacidad embed, que convierte texto en vectores para la búsqueda por similitud. La capacidad extract se puede fijar por tenant (es un ajuste que hace un operador de Ediccio, no un control del cliente); embed, no. Los tenants sin una configuración fijada usan la composición por defecto. La tabla muestra las versiones fijadas actualmente; las actualizaciones de versión dentro de una misma familia de modelos siguen la regla de mejora silenciosa que se describe más abajo, en “Notificación de cambios”.

El respaldo es una composición: el principal atiende todas las peticiones y el secundario solo toma el relevo cuando el principal falla con un error transitorio del proveedor. Ambos modelos se miden de forma independiente con el mismo conjunto de referencia, o golden set, y la composición se cualifica en su conjunto (véase el apartado “Calidad”, más abajo).

Un modelo mejor es una mejora silenciosa del producto. Nunca eliges un modelo, y el nombre de un modelo nunca aparece en una página de precios. Medimos la calidad y, cuando un cambio la mejora, lo desplegamos sin cambiar el contrato; los cambios en el modelo por defecto declarado están sujetos al preaviso de 30 días que se describe más abajo, en “Notificación de cambios”.

El producto de Ediccio trata los datos de los tenants exclusivamente en regiones de AWS de la UE. Los datos de los tenants residen eneu-west-1 (Irlanda). Las llamadas de extracción usan perfiles de inferencia interregionales de la UE (prefijo eu.), así que Bedrock puede ejecutarlas de forma transitoria en otra región de la UE (cada una figura en la tabla “Modelos y regiones” del apartado “Subencargados”, más abajo); las de embedding se ejecutan en eu-west-1. Con la configuración por defecto, la inferencia no sale de la UE.

La afirmación de residencia cubre el transporte, no solo el almacenamiento: los endpoints de la API (mcp.eu.ediccio.ai, con mcp.ediccio.ai como alias) terminan TLS en un frontal regional en eu-west-1, de modo que los datos de los tenants solo se descifran en la UE, también en tránsito. En el plano de datos no hay ninguna CDN.

Dos excepciones fuera de la UE derivan del contrato de AWS y no contienen datos de tenants: Amazon CloudFront (red de borde global, sirve el sitio de marketing, los archivos estáticos del Panel de Cliente y nuestra propia consola de operador, cuyo tráfico son nuestros propios datos como responsable, clientes potenciales y nuestros buzones legales, nunca datos de tenants) y AWS Certificate Manager + Route 53 (us-east-1, plano de DNS y de certificados; CloudFront exige que su certificado esté en us-east-1). Una petición a cualquiera de las tres puede tratarse en tránsito en un nodo de borde de CloudFront fuera del Espacio Económico Europeo, como indica nuestra política de privacidad. Ambas se declaran en la lista de subencargados y su tratamiento queda bajo el paraguas del mismo DPA de AWS.

Si un cliente trajera su propio modelo (diseñado, aún no construido; véase más abajo), la región de ese proveedor quedaría bajo el control del cliente y se haría constar en la adenda al DPA específica de cada tenant.

Nuestros propios canales. La afirmación anterior de tratamiento solo en la UE se refiere al producto. Nuestros propios canales de venta y soporte son distintos: los datos de quienes nos escriben por WhatsApp los trata Meta Platforms Ireland Limited como encargado nuestro, con Meta Platforms, Inc. (Estados Unidos) como subencargado al amparo del Marco de Privacidad de Datos UE-EE. UU. y, como respaldo, de las cláusulas contractuales tipo de la UE; los mensajes de la Cloud API de WhatsApp no están cifrados de extremo a extremo. Es el único flujo en el que datos personales de los que somos responsables llegan a un subencargado fuera de la UE; los nodos de borde de CloudFront citados arriba también pueden tratar en tránsito, fuera del Espacio Económico Europeo, las peticiones al sitio y a la consola, como indica nuestra política de privacidad. Ninguno de los dos toca datos de tenants. El correo electrónico se envía a través de Amazon SES en eu-west-1.

Todo modelo de extracción que llega a producción se mide con el mismo conjunto de referencia: 30 filas repartidas en seis dimensiones (intención, puntos de dolor, sentimiento, preferencias, campos tradicionales y casos adversariales). El arnés de evaluación y el conjunto de referencia están disponibles a petición para que el cliente los revise, y todas las cifras que siguen se pueden reproducir a partir de ellos con un solo comando por configuración.

Mistral en solitario queda por debajo del umbral de cualificación y los clientes no pueden seleccionarlo. Solo actúa como secundario dentro de la composición de respaldo; el respaldo compuesto iguala la puntuación del principal porque el secundario solo se ejecuta cuando el principal falla. Con carga nominal, Claude atiende todas las peticiones.

Las dos omisiones que restan exhaustividad a la configuración por defecto (una intención y un campo tradicional) son discrepancias semánticas entre las etiquetas de referencia elaboradas a mano y las lecturas del modelo, no fallos de extracción. El F1 por dimensión es de 1,000 en puntos de dolor, sentimiento y preferencias.

Ediccio actúa como encargado del tratamiento conforme al artículo 28 del RGPD (y a las disposiciones equivalentes del RGPD del Reino Unido, de la FADP suiza y de marcos análogos). El cliente es el responsable del tratamiento; es quien aporta el end_user_id de cada interesado. El encargado de Ediccio es Amazon Web Services (entidad contratante Amazon Web Services EMEA SARL, con Amazon Web Services, Inc. como parte conjunta conforme al AWS GDPR Data Processing Addendum), solo en regiones de la UE; todos los servicios del plano de datos del producto se ejecutan dentro de AWS. Los propios subencargados de AWS se publican en su página de subencargados y estamos suscritos a sus avisos de cambio. Los modelos que ejecutamos dentro de Bedrock los licencian Anthropic Ireland, Limited (Claude) y Mistral AI (a través de AWS); AWS documenta que los proveedores de modelos no tienen acceso a los logs, prompts ni respuestas de Bedrock, y solo fijamos modelos que se sirven sin retención de datos. El desglose completo por servicio figura en el registro de subencargados del DPA, disponible a petición, de modo que esta página se queda en el nivel de entidad y no se reescribe con cada cambio interno de la arquitectura.

Amazon Bedrock no utiliza nuestros prompts ni nuestras respuestas para entrenar modelos ni los comparte con los proveedores de modelos. Solo fijamos modelos que Bedrock sirve sin retención de datos (Claude Sonnet 4.6, Pixtral Large, Titan Text Embeddings V2), de modo que AWS no escribe ningún prompt ni respuesta en almacenamiento duradero. Bedrock ejecuta una detección automatizada de abusos; para nuestros modelos y entradas de solo texto no almacena contenido. El registro de invocaciones de modelos no está activado.

Modelos y regiones. Los tres identificadores de modelo fijados y las regiones que AWS publica como destino de sus perfiles de inferencia. Última verificación: 2026-10-18.

Milán (eu-south-1) y España (eu-south-2) son regiones de activación opcional a las que un perfil puede enrutar aunque no estén activadas en nuestra cuenta, por lo que figuran en la lista. Las listas de destino son las de AWS, consultadas en la fecha indicada.

Ediccio se compromete a dar a los responsables del tratamiento un preaviso de al menos 30 días ante cualquier incorporación o sustitución de un subencargado, a través del contacto establecido en el DPA. El registro por servicio (qué servicios de AWS se ejecutan y dónde, mantenido en sincronía con la arquitectura) forma parte del paquete del DPA destinado a clientes; los registros de decisiones de arquitectura en los que se basa esta página se comparten junto con él, a petición.

La supresión de los datos de un interesado es un borrado físico definitivo de sus filas en la base de datos del tenant, acompañado de un registro de auditoría sin información de identificación personal (PII). No hay crypto-shredding (se eliminan los bytes) ni borrado lógico seguido de purga (la operación es atómica). El registro de auditoría recoge la solicitud, el rol del solicitante y un hash con sal del identificador del interesado, nunca el identificador en sí.

• SLO de supresión. 30 días desde la solicitud verificada hasta que las filas del interesado ya no sean accesibles en ningún almacén activo. En las copias de seguridad activas, la supresión se hace efectiva en la siguiente rotación de copias, dentro del mismo SLO.
• Copias de seguridad. Recuperación a un momento dado con una ventana de 7 días; no hay instantáneas programadas que se conserven más tiempo. Los datos suprimidos desaparecen de las copias de seguridad al caducar estas en la rotación, dentro de esa ventana.
• Logs operativos. Se conservan 30 días y después se purgan automáticamente. Los identificadores de los interesados (end_user_id) y el contenido en bruto de las señales nunca se escriben en los logs; la PII se depura en origen.
• Telemetría de Bedrock. Bedrock no utiliza los prompts ni las respuestas para entrenar modelos ni los comparte con los proveedores de modelos; los modelos fijados se sirven sin retención de datos (véase “Subencargados”, más arriba) y el registro de invocaciones de modelos no está activado.

Los endpoints DSAR (POST /tenants/{tenant_id}/subjects/{end_user_id}/erasure, POST /tenants/{tenant_id}/subjects/{end_user_id}/export y GET /tenants/{tenant_id}/dsar/{request_id}) se exponen en la Management API. La plataforma de gestión del consentimiento (CMP) del cliente, ya sea OneTrust, Transcend, Ketch o una propia, es el sistema de registro para el consentimiento y llama a estos endpoints desde su flujo de trabajo. Nos integramos con las CMP; no somos una.

La mayoría de los documentos de transparencia se quedan en la arquitectura. Este no, porque la arquitectura sin verificación es una suposición. Los controles de verificación de Ediccio se ejecutan con dos cadencias. Los controles estáticos (lint, comprobación de tipos, la suite de pruebas unitarias y el control de aislamiento entre tenants) se ejecutan en cada pull request, en cada cambio en la rama principal y a diario. Los controles que ponen a prueba la inferencia real con el conjunto de referencia (contra Bedrock real, no contra mocks), la ida y vuelta de extremo a extremo, la conmutación por error y el flujo de derechos de los interesados los lanza un operador y quedan registrados, cada ejecución con su fecha; la tabla del apartado “Calidad” muestra la fecha de la última cualificación de cada configuración.

Cadencia. Las comprobaciones estáticas se ejecutan en cada pull request, en cada cambio en la rama principal y con un cron diario; el control de aislamiento entre tenants, en cada pull request y en cada cambio en la rama principal. Los controles que ponen a prueba la inferencia real y el de derechos de los interesados se ejecutan como un flujo de trabajo que lanza un operador y que queda registrado; las fechas de la tabla del apartado “Calidad” son las de esas ejecuciones.

Registro de auditoría. Las ejecuciones de verificación iniciadas por un operador se anotan en un registro fechado que se guarda en control de versiones y que está disponible a petición junto con el paquete del DPA. A medida que se acumule ese historial, podremos informar del objetivo de disponibilidad del apartado “Disponibilidad”, más abajo, a partir del propio registro y no de una estimación.

La disponibilidad y la tasa de uso del respaldo aún no se pueden medir. El registro de verificaciones necesita un periodo sostenido de historial limpio antes de que las cifras dejen de ser ruido; el objetivo publicado llegará a este apartado cuando el registro pueda sustentarlo.

La postura provisional: Ediccio está en beta privada, así que todavía no podemos informar de la disponibilidad en producción. Hasta entonces, la cadencia de verificación descrita arriba es el indicador indirecto más cercano.

Los perfiles y las señales son inferencias generadas por IA a partir de texto, que se entregan a tus sistemas por MCP con puntuaciones de confianza. Ediccio no interactúa directamente con tus usuarios finales ni trata datos biométricos, así que no es un sistema de reconocimiento de emociones tal como lo define el Reglamento de IA de la UE (art. 3.39: inferencia de emociones a partir de datos biométricos). Aquí, el sentimiento es una propiedad extraída de la conversación escrita, como la intención o una preferencia. Las obligaciones de transparencia del art. 50 aplicables a los sistemas que interactúan con personas corresponden al agente que construyes; lo que Ediccio te debe es inferencia claramente marcada como inferencia: cada observación lleva una puntuación de confianza y un marcador de procedencia legible por máquina en todas las superficies que emiten contenido de perfil.

Finalidad prevista. Ediccio construye un perfil profundo de los propios clientes, clientes potenciales y usuarios del producto de una empresa a partir de las conversaciones que esa empresa ya mantiene con ellos, para que los agentes de IA de su producto (asistente de ventas, copiloto de soporte, bot de onboarding de clientes, agente de éxito del cliente, agente de marketing que escribe a clientes que pueden responderle) puedan personalizar esas conversaciones. No está destinado a utilizarse en sistemas que evalúen a personas a efectos de crédito, seguros o prestaciones públicas, de triaje de emergencias, de contratación de personal o en el trabajo, o de educación o formación, ni como fuente de datos de entrada de dichos sistemas ni como parte de ellos, ni en los ámbitos de la garantía del cumplimiento del Derecho, la migración, la justicia o las elecciones. Tampoco está destinado a elaborar perfiles de los propios trabajadores, candidatos a un empleo, estudiantes, personas en formación o pacientes de una empresa. Una definición de dimensión, campo o recorrido que mencione una categoría especial de datos personales o antecedentes penales (arts. 9 y 10 del RGPD) se rechaza antes de que surta efecto.

La capa de modelos es intercambiable mediante una interfaz, un compromiso de arquitectura permanente, y esa parte sí está construida: la frontera es un contrato de capacidades, los sustratos cualificados están detrás de un registro y un tenant puede quedar fijado a uno de ellos para la extracción. El embedding no se puede fijar: las observaciones almacenadas de todos los tenants se convierten en vectores con el mismo modelo, y las consultas de búsqueda también usan ese modelo.

Lo que no está construido es la mitad orientada al cliente. Apuntar esa frontera al endpoint propio de un cliente, para que su proveedor sea encargado del tratamiento del propio cliente y no subencargado nuestro, está diseñado y aún no se ha lanzado, y lo mismo ocurre con la repercusión del coste del modelo que serviría para ponerle precio. Un cliente que necesite fijar hoy un proveedor concreto, por soberanía, por un contrato empresarial que ya tenga o por coste, debería planteárnoslo en lugar de deducirlo de esta página.

El contrato se define por capacidades (extract, embed), no por proveedores. Dentro de la frontera de modelos de Ediccio no hay streaming, ni llamadas a herramientas, ni superficie de chat. Son ausencias deliberadas; la frontera es estrecha a propósito.

Los cambios en los modelos por defecto declarados o en el conjunto de subencargados se anuncian a los responsables del tratamiento con al menos 30 días de antelación, a través del contacto establecido en el DPA. Los cambios de versión dentro del modelo por defecto declarado (por ejemplo, que Claude, de Anthropic, pase a una versión más reciente de Sonnet) son mejoras silenciosas del producto, salvo que otro modelo pase a ser el modelo por defecto declarado; si eso ocurre, se aplica la regla de los 30 días.

Bajo esta página se va acumulando un registro fechado, en forma de diffs, de los cambios del modelo por defecto.