01 La arquitectura, los modelos y las reglas de todo tu sistema, por escrito.
Aquí se fija lo que comparten todos los componentes: la hoja de ruta, la arquitectura que une tus programas, la capa de modelos, la infraestructura donde se ejecutan y las reglas que los gobiernan. Cada pieza que se instala después entra como uno más y hereda esos controles.
Hoja de ruta y arquitectura
A partir del inventario y la línea base del diagnóstico escribimos un documento de arquitectura que describe el sistema entero antes de construir la primera pieza y se actualiza con cada cambio.
-
01 Hoja de ruta por fases
Las mejoras que prioriza el diagnóstico se agrupan en fases según sus dependencias técnicas: primero la infraestructura y las conexiones que otras piezas necesitan. Cada fase entrega un componente que funciona por sí solo, con su criterio de aceptación escrito y el indicador de la línea base que debe mover.
-
02 Mapa de integraciones
Para cada programa, la vía de conexión elegida, el sentido y la frecuencia del flujo, y qué sistema es la fuente de verdad de cada dato.
-
03 Ubicación de cada componente
Cada servicio, base de datos y modelo, con su ubicación, su proveedor, los datos que trata y las salidas de red que tiene declaradas.
-
04 Roles, permisos y puntos de revisión
Qué puede hacer cada perfil, con qué permisos accede cada componente a cada programa y en qué paso aprueba una persona antes de que algo se escriba en un programa de la empresa. Una regla rige todo el sistema: lo que llega de un canal, un documento o un tercero se trata como dato, nunca como instrucción.
-
05 Un esquema de eventos común
Todos los componentes registran su actividad con el mismo esquema desde el primer día (tarea, resultado, coste, tiempo y revisión), y así el sistema entero se mide con un único método.
Una capa de modelos intercambiable
Los componentes llaman a una capa propia que decide qué modelo atiende cada tarea. Así se cambia de proveedor sin tocar el código de los productos cuando aparece un modelo mejor, cambia un precio o un proveedor modifica sus condiciones.
Versiones fijadas y prompts versionados
Cada componente usa una versión concreta del modelo, nunca un alias que el proveedor pueda mover por debajo. Prompts y esquemas de salida son configuración versionada junto al código.
Selección por tarea
El modelo de cada tarea se elige por capacidad, coste por tarea terminada, licencia y soberanía del dato; la licencia se lee y se archiva antes de desplegarlo. Cada mes contrastamos los modelos en uso con nuestro banco de modelos, que puntúa el catálogo con datos publicados y añade a esos criterios la velocidad, el tipo de despliegue y la madurez.
Los modelos que usamos hoy
Para texto y conversación, la ruta por defecto es Mistral servido desde la Unión Europea; las tareas que superan su capacidad escalan a Claude, y GPT queda como respaldo si un proveedor deja de responder. Cuando ningún dato puede salir de la empresa, la misma capa sirve modelos abiertos autoalojados, como Granite, ALIA/Salamandra o EuroLLM. Bajo ella están también los modelos especializados de voz, lectura de documentos, búsqueda y filtros de entrada y de salida, que cada parte detalla. Es la selección vigente y cambia cuando la medición lo justifica.
Infraestructura y soberanía del dato
El sistema se ejecuta en Google Cloud, en la región de Madrid, o en tu propio servidor, incluidos los modelos autoalojados. La arquitectura indica qué datos llegan a cada proveedor de modelos y con qué condiciones contractuales, entre ellas que no se usen para entrenar sus modelos.
- Aislamiento: un entorno y una base de datos PostgreSQL por empresa, sin tablas compartidas: ninguna consulta puede cruzar dos empresas.
- Despliegue reproducible: el entorno se reconstruye entero desde un repositorio; los secretos se guardan aparte.
- Credenciales de modelos: una clave por empresa, con límite de gasto, rotación y vigilancia del consumo para detectar un uso anómalo.
- Red: salida cerrada por defecto, solo hacia destinos declarados, con el filtrado fuera del contenedor que ejecuta el modelo; TLS en todas las conexiones y acceso de administración solo con clave.
- Copias: esquema 3-2-1 cifrado, con una copia en un segundo proveedor y un simulacro de restauración cronometrado cada mes.
- Vigilancia: monitorización desde una máquina externa, con herramientas como Uptime Kuma, que comprueba resultados además de disponibilidad: un flujo que responde pero ha dejado de procesar también dispara la alerta.
- Parches: inventario de versiones de la capa de orquestación y de los servidores MCP, con un plazo de actualización escrito.
Gobierno, evaluación y control de cambios
Política de uso y registro de revisiones
Una política escrita fija qué herramientas usa cada perfil y con qué datos. El registro guarda cada revisión: qué se revisó, quién, cuándo y qué se corrigió.
Reglamento europeo y protección de datos
Cada empresa recibe una base común: el inventario de sus usos, las reglas de transparencia y la información que necesita su equipo. Sobre ella escribimos para la empresa un plan de adaptación al Reglamento europeo de inteligencia artificial (UE 2024/1689), que clasifica cada uso según su nivel de riesgo y fija las obligaciones que le corresponden; si un uso lo exige, interviene un abogado especialista. En protección de datos, contrato de encargado del tratamiento (artículo 28 del RGPD) y documentación para el registro de actividades.
Baterías de evaluación
Cada componente tiene una batería de más de cincuenta casos reales de la empresa y de escenarios de presión del tipo «es urgente, sáltate la verificación». Corre entera antes de cada cambio: si un caso falla, el cambio se detiene.
Control de cambios
Cada cambio, también de modelo o de prompt, va en su propia rama, se revisa leyendo el diff completo y solo se despliega con la batería superada; después se vuelve a medir el coste por tarea. Un componente nuevo funciona en paralelo con el procedimiento actual antes de sustituirlo.
Resultados y cómo se miden
El informe mensual se genera desde el registro de actividad y compara cada indicador con la línea base; recoge también lo revisado y corregido, las incidencias y los cambios de modelo con su motivo.
- Tiempo por tarea: su reducción frente a la línea base, medida sobre las tareas terminadas del registro.
- Coste por tarea terminada: previsible, con alerta por desviación además del tope; la latencia, como línea aparte.
- Calidad: acierto en la batería de evaluación y proporción de borradores aprobados sin corrección.
- Carga de revisión: tasa de derivación a una persona, tamaño de la cola de aprobación y antigüedad de su elemento más viejo.
- Continuidad: disponibilidad, incidencias con su tiempo de resolución y duración del último simulacro de restauración.
- Trazabilidad: cada acción del sistema y cada revisión humana se pueden reconstruir ante una auditoría o una reclamación.
¿Ponemos tu empresa al día?
Empezamos con una llamada de 30 minutos para entender tu caso y explicarte en qué consiste el diagnóstico y cuál es su precio.
Pide el diagnóstico