01 The architecture, the models and the rules of your entire system, in writing.
This is where everything the components share is set down: the roadmap, the architecture that links your programs, the model layer, the infrastructure they run on and the rules that govern them. Every piece installed afterwards joins as one more and inherits those controls.
Roadmap and architecture
From the inventory and the baseline established in the diagnostic, we write an architecture document that describes the whole system before the first piece is built and is updated with every change.
-
01 A phased roadmap
The improvements the diagnostic prioritises are grouped into phases according to their technical dependencies: first, the infrastructure and connections that other pieces rely on. Each phase delivers a component that works on its own, with its written acceptance criterion and the baseline indicator it has to move.
-
02 Integration map
For each program, the chosen connection method, the direction and frequency of the flow, and which system is the source of truth for each piece of data.
-
03 Where each component runs
Every service, database and model, with its location, its provider, the data it processes and its declared network egress.
-
04 Roles, permissions and review points
What each profile can do, with which permissions each component accesses each program, and at which step a person approves before anything is written to a company program. One rule governs the whole system: whatever comes in from a channel, a document or a third party is treated as data, never as an instruction.
-
05 A common event schema
Every component logs its activity with the same schema from day one (task, outcome, cost, time and review), so the whole system is measured with a single method.
A swappable model layer
The components call a layer of our own that decides which model handles each task. That way the provider can be changed without touching the products' code when a better model appears, a price changes or a provider alters its terms.
Pinned versions and versioned prompts
Each component uses a specific model version, never an alias the provider can move underneath it. Prompts and output schemas are configuration, versioned alongside the code.
Selection by task
The model for each task is chosen on capability, cost per completed task, licence and data sovereignty; the licence is read and filed before the model is deployed. Every month we check the models in use against our model benchmark, which scores the catalogue on published data and adds speed, deployment type and maturity to those criteria.
The models we use today
For text and conversation, the default route is Mistral served from the European Union; tasks beyond its capability escalate to Claude, and GPT stands by as a fallback if a provider stops responding. When no data may leave the company, the same layer serves self-hosted open models such as Granite, ALIA/Salamandra or EuroLLM. Beneath it sit the specialised models for voice, document reading, search, and input and output filtering, which each part describes in detail. This is the current selection, and it changes when measurement justifies it.
Infrastructure and data sovereignty
The system runs on Google Cloud, in the Madrid region, or on your own server, self-hosted models included. The architecture states which data reaches each model provider and under which contractual terms, among them that the data is not used to train their models.
- Isolation: one environment and one PostgreSQL database per company, with no shared tables: no query can cross two companies.
- Reproducible deployment: the whole environment is rebuilt from a repository; secrets are stored separately.
- Model credentials: one key per company, with a spending cap, rotation and usage monitoring to detect anomalous use.
- Network: egress closed by default and open only to declared destinations, with filtering outside the container that runs the model; TLS on every connection and key-only administrative access.
- Backups: an encrypted 3-2-1 scheme, with one copy at a second provider and a timed restore drill every month.
- Monitoring: from an external machine, with tools such as Uptime Kuma, checking results as well as availability: a flow that responds but has stopped processing also triggers the alert.
- Patching: a version inventory of the orchestration layer and the MCP servers, with a written update deadline.
Governance, evaluation and change control
Usage policy and review log
A written policy sets which tools each profile uses and with which data. The log records every review: what was reviewed, by whom, when and what was corrected.
European regulation and data protection
Every company receives a common foundation: the inventory of its uses, the transparency rules and the information its team needs. On top of it we write, for the company, a plan to adapt to the European Artificial Intelligence Act (EU 2024/1689), which classifies each use by risk level and sets the obligations that apply to it; where a use requires it, a specialist lawyer steps in. On data protection, a data processing agreement (Article 28 GDPR) and documentation for the record of processing activities.
Evaluation suites
Each component has a suite of more than fifty real cases from the company and pressure scenarios along the lines of “it’s urgent, skip the verification”. It runs in full before every change: if a case fails, the change stops.
Change control
Every change, including a change of model or prompt, goes on its own branch, is reviewed by reading the full diff and is deployed only once the suite passes; the cost per task is then measured again. A new component runs in parallel with the current procedure before replacing it.
Results and how they are measured
The monthly report is generated from the activity log and compares each indicator with the baseline; it also covers what was reviewed and corrected, incidents, and model changes with their reasons.
- Time per task: its reduction against the baseline, measured on the completed tasks in the log.
- Cost per completed task: predictable, with a deviation alert in addition to the spending cap; latency is reported as a separate line.
- Quality: accuracy on the evaluation suite and the share of drafts approved without correction.
- Review load: rate of escalation to a person, size of the approval queue and age of its oldest item.
- Continuity: availability, incidents with their resolution time and the duration of the latest restore drill.
- Traceability: every system action and every human review can be reconstructed for an audit or a complaint.
Shall we bring your company up to date?
We start with a 30-minute call to understand your case and explain what the diagnostic consists of and what it costs.
Request the diagnostic