Trust, security, and data handling
Public doctrine tools are read-only lookups, and signals.feedback writes only what you explicitly pass; authenticated tools process your code under a strict no-training policy, with a private-session flag that skips the stored run (operational security and cost logs are kept per the Privacy Policy). UK hosting (Google Cloud Run europe-west2); code is processed by OpenAI (US) under the EU SCCs and UK Addendum. DPAs available for Teams. What IT/Legal needs to clear the integration is on the page below.
The Public MCP: read-only lookups, opt-in feedback
The 12 public MCP tools (principles.list, clusters.list, principles.get, examples.search, guides.get, signals.feedback, etc.) work like a public documentation API. The doctrine tools are read-only lookups: the server receives only the structured query parameters you pass, slug strings, search queries, filter values. For IT/Legal review: the public doctrine tools accept only query strings; none reads file contents or codebase context. The one public tool that writes, signals.feedback, takes only the text you give it and fires only on your explicit request. signals.feedback sends its free-text fields to OpenAI (US) for triage only when permission_to_follow_up=true and a valid contact email is given, which also opens a support ticket; the email itself is never sent, and, separately, feedback linked to an account may appear, pseudonymised and shortened, in the extract our weekly lead-intelligence report sends to OpenAI (US).
The Pro/Teams MCP, data handling and zero-training
For practitioners using architect.validate to audit real code: your code is sent to the underlying LLM provider (OpenAI, US) to generate the validation report, on a no-training basis, and retained under OpenAI's API data-retention terms. We do not train models on user code, validation payloads, or architecture diagrams. Ever. Our application layer adds a guarantee: when you pass private_session=true on architect.validate, design.validate, or spec.validate, the server skips the stored run for that call, so AI Design Blueprint persists no copy of your code, artefact, or result on our side; operational security and cost logs, which record the calling client, the client software and version it declares, which install package it came from (a fixed identifier in the plugin manifest, never anything about you), and, on MCP calls, a keyed one-way digest of the network address (a pseudonym, not the address itself), the lookup text or target (a search query, a principle, cluster, or example name, or, for a validator run, the repository and any error text), and whether the call succeeded and how long it took, but never the raw user-agent string itself (only the calling client and declared software/version already listed), and, for validation calls, a request summary (your task or focus area, the repository identifier, up to three file paths and the code language) but never the payload, are retained per our Privacy Policy and are unlinked, not deleted, when you erase your account (OpenAI's own retention is governed by their API terms). signals.feedback writes only the fields you pass, including any free text; signals.report writes, against your authenticated user ID and plan, the event type (the only required field) and, if you pass them, the surface, a rating, workflow stage, whether you'd recommend it, team size, and a brief_context note kept as written (it may appear, pseudonymised, in our weekly lead-intelligence extract to OpenAI). Neither tool reads your prompts, code, or files; they store only what you pass. signals.feedback sends its free-text fields to OpenAI (US) for triage only when permission_to_follow_up=true and a valid contact email is given, which also opens a support ticket; the email itself is never sent, and, separately, feedback linked to an account may appear, pseudonymised and shortened, in the extract our weekly lead-intelligence report sends to OpenAI (US). Retention follows your choice: a standard run keeps a stored run with us and is persisted at OpenAI; a private session keeps no stored run and is not persisted at OpenAI. Our operational security and cost logs, and OpenAI's abuse-monitoring retention, apply to both. Triage is never persisted there, and only standard runs can be certified. Repository scans (the from-repo flow) always run as standard runs; there is no private_session option on that surface.
GDPR, data residency, and DPAs
AI Design Blueprint compute runs on Google Cloud Run, and data at rest, the database and its backups, is in Cloud SQL, kept in the UK (Google Cloud europe-west2, London). One cross-border flow is the code and context you submit to architect.validate / architect.certify, processed by OpenAI in the United States as a sub-processor under the EU Standard Contractual Clauses and UK Addendum (no-training, subject to OpenAI's API data-retention terms); when a standard run scores production_ready we keep the submitted code for 24 hours so architect.certify can verify it, after that it can no longer be used and an automatic clean-up deletes it; private sessions keep no code. Designed in line with UK and EU GDPR data-minimisation principles. The public doctrine tools need no account and no DPA: they need no personal content: the search tools take the free-text query you send, which is logged and may be used to choose guide topics as described below, the other tools take structured IDs, and all of them return public doctrine content; each call writes an operational log row with a keyed one-way digest of the network address, never the address itself. signals.feedback processes a contact email only when you give one with permission to follow up. Document the doctrine tools in your Records of Processing Activities (ROPA) as a reference API with operational logging whose search tools take the free text you send, similar to a public documentation endpoint with a search box. Creating an account is your choice: once you sign in, we process your account data as the Privacy Policy describes, and organisations on the Teams plan can request our standard Data Processing Agreement (DPA) through the support page. The support and partnership forms send your message text to OpenAI (US) for the same triage; name and email are not sent. OpenAI (US) is our sub-processor for AIDB Studio conversations within a plan's included allowance, for conversation summaries and deep research in AIDB Studio on any plan, for the validators' code/context, for support, feedback, and partnership triage text, for the answers on the pilot and agency application forms, and for a pseudonymised weekly lead report, under the EU SCCs and UK Addendum. OpenRouter (US) receives AIDB Studio conversations on the Basic plan and once any plan's included allowance is used; we ask it to pass each one only to a model provider it lists as not collecting user data. Tavily, a web search provider, receives the search queries from AIDB Studio's deep research, and from web search when your chat does not run directly on OpenAI. We may also use the search text sent to the public MCP search tools to choose guide topics. Only a term searched by at least three distinct callers (an account, or a network-address digest) is considered; a shortlisted term goes to OpenAI (US) to be mapped to a principle; a chosen term is the research query Tavily receives under its own terms (or OpenAI web search, when Tavily fails or finds nothing), and OpenAI (US) drafts the guide and its cover image. The text requests to OpenAI are not kept in its response store; OpenAI's abuse-monitoring retention applies.
Signal tools, explicit opt-in only
signals.report needs a signed-in Pro, Pro Plus, Teams, Enterprise, beta, or trial plan and is offered by the agent only after a validator run (any lens) or a doctrine session, only after the user confirms the session was valuable. signals.feedback is open to all callers but must only be called when the user explicitly says they want to leave feedback. Neither tool is ever called automatically or silently. See the privacy policy at aidesignblueprint.com/en/privacy for the full data handling contract.
Also in this section