The Architecture of Sophron

Premise: Sophron is a scaffold, not an AI

The first misunderstanding to clear up is one of vocabulary. When we say «Sophron», we mean a system that does things — analyses requests, executes change requests, watches logs, answers business questions in plain Italian. Each of these things, taken alone, is today within reach of any system based on a modern language model with access to company data. Sophron does not take its meaning from the «what».

Sophron is the why and the how of those things: the shared data model that describes corporate knowledge, the routing mechanism that decides which knowledge is needed for a given task, the operational rules the router applies to every answer, and the shared work discipline that the team agrees to in order to produce information reusable by the others. On top of this scaffold an LLM runs, which the scaffold uses as cognitive substrate. The LLM is the engine. The scaffold is what makes it useful to a company instead of to a single user.

One clarification, before continuing: the scaffold in itself is model-agnostic. In principle Sophron can work with any modern LLM endowed with tool-use capabilities, filesystem access and a sufficiently large context window. The concrete choice came from an evaluation based on use case (CLI interaction, tool execution, long dialogues requiring large context windows) and on the performance observed in the field in the following months. Today, in Sophron, we mainly use Claude Code (by Anthropic) as the execution environment, with the Claude 4.x family as cognitive engine — in particular Opus 4.7, Sonnet 4.6 and Haiku 4.5, chosen case by case depending on the task. The discussion that follows describes the scaffold; the fact that Claude runs underneath today is a consequence of the evaluation, not an architectural premise.

The main parts of the scaffold are four: the 4 axes of knowledge classification, the cognitive router, the 16 R-* disciplines the router applies, and the multi-domain architecture that lets the system operate on different contexts at once. We describe them in order.

The four axes: the knowledge data model

Every knowledge artefact inside Sophron — a concept, a skill, a convention, a procedure, a domain manifesto, a documentation line — is classified along four orthogonal axes. They are the minimum set of dimensions with which one can describe a piece of corporate knowledge so that a router knows whether it is relevant to a task. Removing one means losing filtering capacity; adding a fifth turns out to be redundant.

Domain — what we are talking about

The first axis answers the question «inside which functional perimeter does this knowledge live?». The values are the domains instantiated in the system: crm, sap-integration, pbi-analytics, documental, it-infra, eam, hub, mmc-intranet, solarlog, unafinestrasuivalori, sql-platform, utility-services, plus the meta-domain cross-domain.

The Domain is not a cosmetic label: it is a real boundary of information existence. A ticket opened by the customer in the CRM, for example, lives only inside the CRM database and is never replicated in SAP. If the router does not know that a ticket is the crm domain, it may go searching for information in SAP that is not there.

Layer — the kind of knowledge

The second axis answers the question «what is the nature of this knowledge?». The values are: concepts (abstract rules), databases (data structures), applications (live programs), infrastructure (servers and network), conventions (work patterns), skills (reusable operational procedures), channels (communication channels), users (profiles and roles).

The same real object can be described across different layers: the ticket from the example is a concept (what a ticket is, what its lifecycle is, who can change its state), it is a database (in which tables it is written), it is an application (which CRM interface handles it). The Layer tells which aspect we are talking about.

Env — environment of applicability

The third axis answers the question «in which environment does this information apply?». The values are base, dev, tst, prd. Env is especially relevant for the databases and applications layers: a procedure tested in tst is not the same procedure in prd, and giving a recommendation about tst that gets applied to prd is the fastest way to produce an incident.

Env is the dimension that weighs the gravity of an answer, not just its correctness. Sophron must know which environment is at stake before proposing an action.

Status — the composite axis of reliability

The fourth axis is not a single scalar: it is the composite of three sub-dimensions that together describe how much you can trust a piece of knowledge at a given moment.

• Freshness — how recent the last verification of the knowledge is. Old freshness does not mean wrong, but it means to be re-verified.
• Authority — from which source the knowledge comes, and what priority it has compared to others. The canonical order is: code > observed > docs > teams > inferred. Active code wins over documentation; documentation wins over a team chat; a chat wins over an inference.
• Lifecycle status — which phase of the lifecycle it is in: draft, active, deprecated, archived.

Status is the guarantor of reliability: the piece that says whether you can trust right now or whether you have to re-verify first.

Combination and projection

Together, the four axes define a point in a classification space that the router can query with synthetic queries such as «load all concepts of domain crm, in env=prd, with status=active and freshness no older than six months». The operational advantage is that the router does not bring into the LLM's context the whole knowledge base — it brings only the projection relevant to the task. This is what separates Sophron from a system doing load-all.

The cognitive router

The cognitive router is the component that, on every incoming message, executes a fixed sequence of steps and decides what to provide to the LLM as context. The sequence is deterministic: no hidden heuristics, no defensive «load-all». It is documented in .ai-docs/cross-domain/skills/sophron-router.md.

The steps, simplified, are as follows:

1. Identify user — who is asking, what role they belong to, which orthogonal skills they are enabled for.
2. Focus + briefing + inbox check — which project they are working on, whether there is a daily-opening note, whether there are inter-user messages to deliver before answering.
3. Classify domain — derived from CWD, paths in the prompt, project context, or explicit question to the user.
4. Classify env — the environment of applicability of the answer.
5. Classify intent — analysis, modification, execution, read, etc.
6. Load only the relevant layers — project the knowledge base on the 4 axes filtered for that task.
7. Apply the 16 R-* disciplines — check on every answer, before delivery.
8. Answer, update state — the answer enters the system's furrow of knowledge, weighted by the user's role.

What the router does not do is equally important: it does not improvise, does not silently choose when ambiguous, does not load «defensively» when uncertain. Its base discipline is: if you don't know, stop and ask.

The sixteen R-* disciplines

The R-*'s are the concrete rules the router applies to every answer. Sixteen rules may seem a high number; grouped by operational family, they become six common-sense principles, each with its purpose. The canonical documentation is in .ai-docs/cross-domain/skills/sophron-discipline.md; here we present them by group.

4.1 Placement — where a piece of knowledge sits

R-DOMAIN requires every task to be associated to one or more explicitly declared domains. Sources in decreasing priority: CWD inside a known Gitea repo, paths cited in the prompt, explicit prompt, project context. Default if ambiguous: ask the user, never silently default.

R-ENV-1 requires every technical answer to declare the env of applicability (dev/tst/prd/base), even when implicit. R-ENV-2 requires explicit mention when an information only lives in some envs: it prevents drift between environments, where a recommendation on tst ends up applied to prd by inattention.

R-LAYER requires that layers (DB/BE/FE) are not mixed without explicit separation. An answer touching multiple layers must label and keep them distinct.

4.2 Reliability — how much one can believe

R-AUTH establishes the authority order in case of conflict among sources: code > observed > docs > teams > inferred. If the documentation says one thing and the code says another, code wins — and Sophron declares the conflict.

R-FRESH imposes a freshness threshold: information older than six months without re-verification is marked as possibly stale, and Sophron declares it before returning the answer.

4.3 User behaviour — who is asking

R-ROLE requires the answer to be filtered by user role: verbosity, permissions, tone. A sysadmin gets technical detail; a sales key user gets business concepts; a visitor gets introductory phrasing.

R-SKILL adds an operational safety layer: certain actions — knowledge rebuild, concept editing, ERP writes — are gated by specific skills declared in users.json. If the user does not own the required skill, the action is blocked hard, with no silent override.

4.4 Cross-domain risk — when a request touches multiple areas

R-CROSS-SAFETY requires that, before modifying a shared resource, the impact on all domains using it be checked. A change in cross-domain conventions, for example, is not executed without first checking what changes for each domain.

R-CROSS-ROUTE requires that, if the declared intent belongs to a domain different from the active one, the router redirect explicitly, declaring the jump.

R-CROSS-SKILL allows loading an authoritative skill from another domain when the knowledge is needed, but always declaring it: no silent imports.

4.5 System hygiene — secrets

R-SECRETS requires all system credentials to live in a single central file (.sophron-secrets.json, gitignored). No scattered auth files, no hard-coded credentials elsewhere. It is a seemingly trivial rule, but the one that keeps the system from leaking secrets by accumulation.

4.6 Team coordination — Sophron as multi-user platform

The last four disciplines are those that turn Sophron from an individual assistant into a team platform. They are activated at the user's first prompt of the day, or at every message.

R-MORNING requires an automatic briefing at the first prompt of the day (or after a gap longer than eight hours): what happened in the team, on which projects, which decisions.

R-INBOX requires that inter-user messages be delivered before processing the user's request: no lost messages, no waits.

R-FOCUS keeps a silent auto-tracking of the project the user is working on, so that subsequent answers are contextually coherent.

R-TASK-INGEST disambiguates the intent of a task requested with natural phrases («note this down», «remind me of X», «done Y»): personal or project? Never silent default — it asks.

Summary table of the sixteen

What holds them together is not the number but the principle: the router never improvises. Every decision — what knowledge to load, how to address the user, whether to execute or block an action — goes through one of these rules. Sixteen occasions to be stopped before answering.

Multi-domain: five types, twelve instances

Sophron is multi-domain by design from the start. The domains instantiated today are twelve, grouped in five types of domain, each with its lifecycle and its source of authority.

The distinction between types matters because it defines where the truth of a datum lives: in a development domain truth is in the code of the repository; in an infrastructure domain truth is in the observed state of the system; in a data-only domain it is in the live dataset. Sophron knows to query the right source for the right type.

It is worth noting that the multi-domain structure was not an explicit design from day one. Sophron 1.0 was mono-domain (CRM only). The multi-domain architecture described above is the result of a targeted redesign that defined the 2.0 version. You can see it in the names: the software is called Sophron 2.0 because there was a Sophron 1.0 before.

Sophron 2.0 (client) and Sophron 3.0 (client-server)

The current state of the scaffold is Sophron 2.0: purely client architecture. Each team user runs their own Sophron on their own client (an AI agent with access to systems via MCP), and every Sophron program — the rebuilder, the sentinels, the discoveries — is manually triggered from the client. There is no server-side daemon running in background.

This is an architectural constraint, not an implementation limitation. It was chosen for operational reasons — deployment simplicity, exposure control, alignment with how AI agents are distributed today. It works, but imposes three clear limits:

• No continuous vigilance: the sentinel must be launched, it does not run in background.
• No real synchronous multi-user: each client works on a snapshot of the knowledge base, and integration between clients passes through Git commits.
• No event-driven triggers: the system reacts when the user makes a request, not when an external event (a CVE, an unprocessed order, a certificate expiry) would call for it.

The expected evolution is Sophron 3.0, currently in design phase (workstream E, paused awaiting closure of 2.0). 3.0 introduces a client-server architecture: an always-on server, program scheduling (sentinels every night, rebuild every morning, db-distributed agent continuously), event-driven triggers (a push on Gitea activates the Skill Sentinel on the touched files), real synchronous multi-user (asynchrony without conflicts), and multi-LLM orchestration (multiple models working in parallel on different tasks).

For the technical reader it is worth clarifying: 3.0 is not a marketing promise, it is a design declared in the document 008-sophron-server-build-brainstorming.html inside workstream E. What is still hypothesis there (e.g. which scheduling technology, which event broker) is written as hypothesis; what is instead settled architecture (client/server separation, synchronisation schema, multi-LLM model) is declared.

The programs that make the scaffold work

The scaffold is not only theory. It lives thanks to a set of programs operating in the .devtools/ folder of the repository, each with a precise task and a development history that often starts from a contingent need of the team. We group them in three families, telling them in the order they were born.

7.1 Discovery — the programs that read the world

The first group is that of discovery programs. Their task is to read the real sources of the business on behalf of the system, and translate them into the classified representation that Sophron's knowledge base can query. They are the «autonomous explorers» feeding the model of the world on which the router then works.

The two most important programs of the group are two parallel indexers, one for code and one for databases. They are deliberately separate (internal architectural decision D009: separated responsibilities, no common wrapper), because speaking to code and speaking to a database are different technical problems, and mixing them produces fragile tools. Together, however, they build the complete picture that lets the system answer cross-module analyses.

The repo-indexer is the code indexer. It deals with Gitea repositories — applications, services, frontends — and is a multi-language parser: PHP CodeIgniter 4 for legacy applications, TypeScript with Node for new services, Vue for recent frontends, with extensions in progress to C#/.NET and Python. It walks the code and extracts semantic indexes: classes, HTTP endpoints, stored-procedure calls, dependencies among components. On the stored-procedure side its map is code-side: it says which endpoint invokes which procedure, not what that procedure does inside the database — that is the job of the second indexer. It has a sub-tool, enumerate-subprojects, working at a higher abstraction level: when a repository contains multiple sub-projects — frequent in corporate monorepos — it recognises them and maps them individually.

Mirror to repo-indexer, on the database front, is rebuild. While repo-indexer reads the code, rebuild reads the live databases: it connects to MSSQL and MySQL (it is multi-engine) and extracts the full structural inventory — tables, columns, foreign keys, stored procedures with their body, views, indexes. On this extraction it builds Sophron's .ai-docs/ knowledge base: description files for each DB object, foreign-key maps, SP usage maps (who calls whom, on the DB side). When a DB object has no comment, an LLM layer (Haiku for triage, Opus for hard cases) generates a propose-only description from the SP body or the table name. It is a heavy program, rebuilding in a few minutes the full representation of six production DBs; its execution is gated by the Rebuilder skill — R-SKILL hard, because an unchecked rebuild could overwrite hand-written descriptions in the concepts.

When a cross-module analysis asks the system «if I modify this endpoint, which stored procedures will it call, and which tables do those SPs act on», the answer arises from the composition of the two maps: repo-indexer provides the first hop (endpoint → SP), rebuild provides the second (SP → tables, via SP usage and FKs). Neither of them, alone, can answer.

The document-classifier works on a very different domain: manuals. Schüco has accumulated over the years terabytes of technical documents — manuals, user instructions, training material — and the problem there is not reading, it is figuring out what is still valid. Document-classifier uses a two-speed system: rapid triage with a fast model (Claude Haiku) for the majority of documents, deeper analysis with the best model (Claude Opus) only for cases the triage marks as low confidence. All in propose-only pattern — it proposes lifecycle and topic labels, it does not apply them without human confirmation. It was one of the first programs built with the awareness that document volume was unmanageable for a human being in reasonable time, but that an AI without a triage protocol would consume resources for nothing.

The sap-reader is probably the one with the most immediately perceivable value in a company that uses SAP. Its job is to read SAP via RFC, through the standard function modules (BAPIs). The MVP was closed on 24 April 2026, and produces autonomously structured documentation on a SAP perimeter — it is the one responsible for the Y_PROFILE HTML that the reportage «AI Is the Engine, Not the Heart» describes in the opening scene. Subsequent phases (F2 and F3) will extend its coverage to other areas of the ERP.

Alongside these three main tools there are two more, more oriented to system governance than to knowledge production. The teams-channels-bridge automatically keeps aligned the map between the Microsoft Teams channels where the team discusses and the Sophron domains those discussions relate to — a surgical edit that preserves comments and avoids drift between how we talk in chat and how our knowledge base is structured. The domain-init is instead the bootstrap program: when the team decides to add a new domain to the system — it happened, for instance, with documental and it-infra — domain-init builds the initial structure of the domain in a guided way, lays down the conventions, and takes care of the first manifesto.

Closing the group are the two MCP servers — mcp/mssql-mcp-python and mcp/teams-mcp-python. They are the interface the LLM uses to access live sources: the first gives access to six MSSQL databases (CRM, MMC Intranet, PBI Analytics, SAP, SQL Server, Utility); the second to the Teams channels whitelisted in the configuration. They are deliberately read-only by default, an explicit choice tied to the R-CROSS-SAFETY discipline discussed in §4.

7.2 Sentinel — the programs that watch

The second group is that of sentinels. While discovery programs build the representation of the world, sentinels watch over the state of something already built — be it the knowledge base itself, the integrity of systems, or the use of data. All in propose-only pattern: they generate patches in diff format, they do not apply them directly.

The privacy-sentinel was the first of the group to be built. It lives as a sub-tool of the rebuilder, in .devtools/rebuild/src/privacy_sentinel.py. Its job is GDPR audit of AI accesses to the databases: it checks the queries AI sessions made on the DBs and flags potential violations — queries on sensitive fields without authorisation, mass-extraction patterns, accesses to personal data without justification. It does not block, it flags. It was the simplest to implement because it has clear boundaries and a clear regulatory reference.

The Skill Sentinel is the great architectural declaration of Sophron 2.0, built in ten sub-tasks (D9.1–D9.10). Its job is to keep custody of the knowledge-base quality — verify consistency among skills, check that each thing is positioned in the right place according to declared conventions, recognise when an analysis is mature enough to deserve becoming a reusable skill, and stop format drift. Four distinct functions — Consistency, Placement, Extraction, Format — operating on five families of files. Here too propose-only pattern: it generates the patch in diff format, it never applies it.

The db-distributed-agent is the sibling of the Skill Sentinel with disjoint scope: it watches over the structural parity of DBs with distributed topology — today utility and sql_server, two databases that by architectural choice must remain structurally identical across environments. Four-stage pipeline: inventory (what is where), diff (what changed), classify (the severity of drift — blocker, schema-drift, code-drift, cosmetic), report (what to do about it). Eight sub-tasks planned, not yet implemented.

7.3 Quality Gate and base infrastructure

The third group is more heterogeneous, but useful to name because it shows that Sophron is not just «the AI that does things»: it has around it a technical infrastructure that inhabits it, and that is itself part of the value.

The Sophron Quality Gate is the control program on Gitea Actions pull requests, part of workstream C, owner James. It catalogues base rules R1–R13 — stored-procedure naming conventions, ban on SQL inline in source code, ban on hard-coded secrets, mandatory authentication on new endpoints, coherence between project ID and domain, rebase coherence, DB migration control — and applies them on PRs. Release mode is warning-only: it does not block merge but flags, so as not to interrupt team flow during rollout; an override label allows IT to force the merge in case of emergency, and overrides are logged for subsequent audit. Sophron Quality Gate is, among other things, its own first guinea pig — its rules are first tested on Sophron's own PRs.

The presenter is a cross-platform Text-to-Speech tool, based on a Chromium browser controlled via Playwright, for reading HTML documents aloud. Born to listen in the car to reportages before committing them — a practical team habit — it has become a small internal classic.

The diagrams is the Graphviz-based diagram generator, used in analysis documents to produce architecture maps without having to leave for an external tool.

Finally common is the central helper, and — on closer look — is one of the most important tools of the whole stack, even if it does not «do» anything visible. It contains the unique secrets-reader (the operational reference of R-SECRETS), the shared LLM helpers, the shell utilities. It is the base infrastructure that all tools above reuse to avoid code duplication and to guarantee that the centralised-secrets discipline is transparently respected. When we say Sophron's scaffold is well built, we mean in good part this: that common exists, and that the other programs really use it.

Security: the condition for AI delegation to be possible

A chapter that closes the previous ones, and that declares something that until here has remained in the background.

Security, in Sophron, is not a feature added on top of a pre-existing system. It is not a firewall placed downstream, an audit log enabled in production, an access control negotiated after the incident. It is the condition for everything else to exist: without security, nothing is delegated to AI. And if nothing is delegated, the multiplier the reportage «AI Is the Engine, Not the Heart» talks about does not activate. Sophron without security is not a less protected version of Sophron — it is a different thing, that cannot even start.

The pieces of security are distributed across all the scaffold described in the previous chapters. It is worth reviewing them together, because read as a chain they have a logic that, taken separately, you cannot see.

8.1 The closed perimeter: whitelist on the repository structure

The first layer of security is structural, not operational. The repository root has a strict whitelist: you can only create folders and files explicitly declared. The same goes for .ai-docs/, the knowledge-base folder, which admits only declared domains and the planned meta-paths (.generated/, .docs/, .teams/). No accidental attack surface from configuration files left in unforeseen places, no silent structural drift over time. If a new folder is needed, it must be explicitly added to the whitelist with a dedicated commit — and modifying the whitelist is itself a controlled act.

8.2 Secrets in one place: R-SECRETS

All secrets — API keys, passwords, tokens, certificates — live in one single gitignored file (.sophron-secrets.json) read through one single module (common.secrets). No credentials hard-coded elsewhere, no auth files scattered among different tools. It is a seemingly bureaucratic rule but with a concrete effect: six months into running the system, the secret inventory is where it should be and no secret has escaped to places it shouldn't be. The privacy-sentinel described in §7 works on top of this discipline, checking that AI accesses to databases respect the boundaries declared by the centrally managed keys.

8.3 Elevated actions gated by skill: R-SKILL

Certain actions — a knowledge-base rebuild, a concept edit, a write to SAP — are gated by specific skills declared in users.json. If the user invoking the action does not possess the required skill, the action is blocked hard, in the tool's own code, before the LLM can even accept to execute it. There is no silent override, no implicit emergency bypass. If an exception is really needed, it must be created explicitly by whoever has the role to do so, and the event is logged. It is the difference between a system where «in theory nobody touches this» and a system where in code nobody really touches it.

8.4 Verify before modify: R-CROSS-SAFETY

Shared resources — a concept used by multiple domains, a skill living in cross-domain, a procedure touched by multiple applications — are not modified without first verifying impact on all consumers. The rule R-CROSS-SAFETY makes this verification mandatory: the router does not let a modification on a shared resource start without the LLM having made explicit the perimeter of who gets impacted. This is what prevents Sophron from breaking the flow of one domain while correctly answering a request on another.

8.5 Authority order: R-AUTH

When two sources say different things — code says X, documentation says Y, a Teams chat says Z, the AI suggests W — Sophron chooses deterministically, according to: code > observed > docs > teams > inferred. Live code always wins, because it is what actually runs. It is a security rule in the full sense: it guarantees that the system's answer never relies on an AI inference when an authoritative source exists. On top of this rule sits the freshness discipline (R-FRESH): if the cited authority has not been re-verified for too long, Sophron declares it before returning the answer.

8.6 Sentinels on real systems

On the perimeter more traditionally perceived as «security» — IT infrastructure — Sophron applies the security-sentinel discipline described in the reportage. It is the one that does the morning roundup of CVEs published over the weekend, flags unusual SSH accesses to production servers, monitors TLS certificate expirations. Today it works in trigger-based mode imposed by the 2.0 architecture (manually launched by the infrastructure manager's client, every day); it will become event-driven in 3.0 — a published CVE will automatically trigger the roundup, without need for a click.

8.7 The principle below it all: rules as the price of delegation

The six layers above — structural whitelists, centralised secrets, gating of elevated actions, cross-domain verification, authority order, sentinels on systems — may seem, taken separately, each a bureaucratic rule. Read together, they are something else.

Sophron lets the team allow AI to do, autonomously, work that until yesterday required six people in three different offices. That autonomy makes sense only if those who delegate can turn their back on the system knowing it will do its job well. Without the guardrails, nobody trusts; without trust, autonomy does not activate; without autonomy, the multiplier does not start. The rules are not the product. They are the price you pay to use the product seriously.

That is why — in a company that wants to use AI as a true substitute for human work, not as a luxury assistant — security cannot be added later. It has to be built before the AI, under the AI, above the AI. Sophron is the attempt to do it transparently to the user: you do not see it while it works, you would only see it if it were missing.

The external provider: trusting an LLM that sees our data

Everything we described until here — axes, router, disciplines, tools, sentinels — concerns the internal security of the scaffold. But there is a question that, in a serious company, gets asked even earlier: how can one trust an LLM, hosted outside our perimeter, to read all the corporate knowledge? Code, DB schemas, configurations, process data, team conversations. A useful AI, to be useful, must see. And seeing, for a cloud service, means data transits through an external provider.

It is not a question to brush aside with two lines in a compliance appendix. It must be tackled, because without a solid answer the delegation §8 talks about does not start. It is a question the Sophron team has explicitly asked, and to which it answered with a formal evaluation — options, real adoption costs, mitigations, long-term direction. We summarise the outcome here.

9.1 The evaluation and the choice

The team structurally compared different paths: the official Anthropic subscription (Team Premium for interactive work, API for programmatic workflows), Claude delivered through intermediate clouds with EU data residency (AWS Bedrock, GCP Vertex AI), and a family of European non-Anthropic alternatives (Mistral, Aleph Alpha, Azure OpenAI, OVHcloud).

The operational choice fell on Anthropic Team Premium for daily IDE work, with the Anthropic API kept as a planned complement for when Sophron will need programmatic AI calls. Intermediate clouds were ruled out for an operational cost disproportionate to a team of our size, considering they deliver basically the same Claude from Anthropic with the same contractual clauses. European non-Anthropic alternatives were ruled out for a still significant quality gap on our agentic-coding use case, and because the tool the team uses daily — Claude Code — is a proprietary CLI inseparable from the model: changing model would mean losing the tool.

What remains is the material point: with Team Premium or Anthropic API, data passes through US servers. We do not pretend that is not an issue. We honestly ask instead — what risk is it, exactly, and how do we mitigate it?

9.2 How the «data in the US» risk is mitigated

On the contractual side, the Anthropic Commercial Terms applied to the for Work plans (Team Premium and API) explicitly exclude using data for model training. This is the crucial point: we are not handing over Schüco know-how to the public Claude model. Data passes through Anthropic servers to be processed and returned, with no retention beyond the session and no reuse for training.

On the certification side, Anthropic is SOC 2 Type II and ISO 27001, with a DPA (Data Processing Agreement) available for European customers. Transit is TLS 1.2+, and in case of data breach there is a contractual commitment to notify within 72 hours, in line with article 33 of GDPR. They are the same certifications comparable EU providers have.

On the nature of the data: it is important to be precise. Sophron works on code, database schemas, technical documentation, process conversations. It does not work on end-customer records — and this not by editorial self-regulation, but by technical construction. Beyond the application-level protections described in §7 (the privacy-sentinel that audits AI accesses to DBs) and in §8 (centralised secrets, skill gating, authority order), the database user with which Sophron authenticates to the ERPs has explicit DENYs, server-side, on the records tables. Even if the model wanted to read a personal field, the database denies it before the request becomes a result. The exposure actually passed to the external provider is therefore industrial in nature (intellectual property, process know-how), not strictly-GDPR like for personal data. The «US governmental requests via CLOUD Act» vector is theoretical but proportional: we are talking about code of internal applications, not the database of natural persons — which from Sophron, simply, is not reachable.

Summary: Schüco's EU residency policy remains the strategic goal, it is not abandoned. The short-term exception is documented, motivated by the absence of equivalent alternatives, and balanced by substantial contractual guarantees on non-training, by industry certifications, and — on the internal side — by a deliberately narrow data-access perimeter. It is not the destination state: it is the pragmatic compromise while the destination state matures.

9.3 The long-term direction: internal server or EU VPS with open-source frontier

The strategic direction of the team is clear: self-hosting. An internal server (Schüco datacentre) or a VPS in EU region hosting a frontier open-source AI model executed locally. This would eliminate the dependency on the US provider and give full compliance with corporate policy.

The constraint, today, is technical rather than organisational: no public open-source model yet reaches Claude's quality on our specific use case (full-stack development, multi-step agentic coding). The Llama family, DeepSeek-Coder, Qwen2.5-Coder, Codestral are being tested and improve rapidly — the realistic estimate is that the gap closes in the next twelve to eighteen months. When an open model reaches the required quality threshold, the team will already have built the necessary AI-ops competencies (vLLM/Ollama orchestration, GPU hardware tuning, compatible API serving) and will be able to migrate. The integration with Sophron is designed from now not to break: the scaffold talks to the LLM through an interface, not through a vendor dependency.

9.4 Why this matters, beyond the technical detail

The opening question of the chapter — «how does one trust an LLM that sees all our data?» — is not answered with reassurance. It is answered with a posture: trust is not an absolute, it is a function of real risk, of existing mitigations, of the reversibility of the choice and of the existence of a credible trajectory toward a better point.

The team made all four components explicit: it measured the risk (training excluded, known certifications, industrial nature of the data), assessed the mitigations (Commercial Terms, DPA, TLS, audit log), confirmed the reversibility (corporate knowledge lives in internal git repositories, not on Anthropic servers — on migration day, data does not have to be recovered: it is already here), and there is a declared roadmap toward full EU residency.

This is what is meant, in practice, by consciously trusting: not stopping to ask the question, but having instructed it in full. Sophron — as a scaffold — is agnostic with respect to the model underneath, and to the servers that model runs on. The day the model and the servers will be internal, the scaffold will not notice. In the meantime, the compromise is explicit, and it is the compromise that allows working today on a version of Sophron where tomorrow the provider may change without having to rebuild anything.