Visión general de la arquitectura

Esta página es un mapa de alto nivel de cómo encaja Syncanix: qué ocurre cuando un usuario le pide algo al asistente, cómo se usa su identidad y dónde residen tus datos. No necesitas nada de esto para empezar, pero ayuda a entender la forma del sistema.

Cómo fluye una solicitud

Tanto si la solicitud llega desde el widget integrado como desde un cliente MCP, se sigue el mismo recorrido:

1. 1
   El usuario preguntaUn usuario autenticado escribe una solicitud en el widget, o la envía desde un cliente MCP como Claude Desktop.
2. 2
   Syncanix planificaEl asistente coteja la solicitud con tu catálogo de capacidades y decide qué acciones de tu API, si las hay, la resolverían, deteniéndose para pedir confirmación cuando una acción modifica datos.
3. 3
   Tu API actúaLas acciones aprobadas se ejecutan contra tu propia API como ese usuario, usando su identidad de tu proveedor de identidad. El resultado vuelve a la conversación y la llamada queda registrada en el registro de auditoría.

Las credenciales de tus usuarios nunca llegan a la IA

El asistente trabaja a partir de una descripción estructurada de lo que tu API puede hacer, no de las contraseñas ni los tokens de sesión de tus usuarios. Cada acción se ejecuta con la identidad propia del usuario final, facilitada por tu proveedor de identidad en el momento en que se necesita. El modelo de lenguaje ve la solicitud y el catálogo; nunca posee una credencial de la que pudiera abusar.

Fiable por diseño

Syncanix enruta hacia más de un proveedor de IA (Anthropic y OpenAI, además de AWS Bedrock en la UE) y conmuta por error automáticamente si uno no está disponible, de modo que la caída de un único proveedor no deja sin servicio a tu asistente. También puedes aportar tus propias claves de proveedor.

Dónde se ejecuta

La infraestructura de Syncanix se ejecuta íntegramente en la Unión Europea — en AWS en Fráncfort (eu-central-1) — con sus datos cifrados en reposo. Las respuestas de chat las genera de forma transitoria el proveedor del modelo según sus términos de API (excluidas del entrenamiento; acuerdos ZDR en formalización); los embeddings de recuperación y el reranking permanecen en la región en Amazon Bedrock.

Tus datos siguen siendo tuyos

Cada espacio de trabajo está aislado de los demás. Una solicitud siempre se limita al espacio de trabajo al que pertenece —en la base de datos, las cachés, los registros y los archivos almacenados—, de modo que un cliente nunca puede ver los datos de otro.

Desarrolla y luego promueve

Cada espacio de trabajo tiene dos entornos: un entorno de desarrollo para configurar y probar con seguridad, y un entorno de producción al que llegan tus usuarios. Haces los cambios en desarrollo y los promueves a producción cuando estás listo, de modo que el comportamiento en vivo solo cambia de forma intencionada.

Próximos pasos